Mon blog

Le format FLAC, normalisé dans ce RFC, permet de stocker et de transmettre du son sans perte (contrairement à des mécanismes de compression comme MP3). Il est donc utile, par exemple pour l'archivage à long terme (mais aussi pour la haute fidélité).

Le multimédia, c'est compliqué. Le RFC fait près de 100 pages, pour un format audio qui se veut pourtant simple. FLAC fait de la compression pour limiter l'espace de stockage nécessaire mais en prenant soin de permettre une décompression qui redonne exactement le fichier originel (d'où le « sans perte » dans son nom, qu'il partage avec d'autres formats, comme le FFV1 du RFC 9043). Je ne connais pas assez le domaine de l'audio pour faire un résumé intelligent du RFC donc je vous invite à le lire si vous voulez comprendre comment FLAC fonctionne (les sections 4 à 6 vous font une description de haut niveau).

Si on prend un fichier FLAC, un programme comme file peut le comprendre :

% file Thélème.flac
Thélème.flac: FLAC audio bitstream data, 24 bit, stereo, 44.1 kHz, length unknown  
  

Le fait que l'échantillonage soit à 44,1 kHz est encodé dans les métadonnées (cf. section 9.1.2 du RFC), que file a pu lire (section 9.1.3 pour le fait que le fichier soit en stéréo).

Il y a quelques fichiers FLAC sur Wikimedia Commons. Mais un bon exemple de l'utilisation de FLAC est donné par l'enregistrement des Variations Goldberg par Kimiko Ishizaka, que vous pouvez télécharger en FLAC et sous une licence libre (CC0).

La mise en œuvre de référence de FLAC est en logiciel libre et se nomme libFLAC. Mais il existe beaucoup d'autres programmes qui savent gérer FLAC (j'ai écouté plusieurs fichiers FLAC avec vlc pour cet article), le lire, l'écrire, l'analyser, etc. Une liste est disponible sur le site du groupe de travail IETF. Il faut dire que FLAC, bien qu'il vienne seulement d'être normalisé, est un format ancien, dont le développement a commencé en 2000, et il n'est donc pas étonnant que les programmeur·ses aient eu le temps de travailler.

Si vous voulez ajouter du code à cette liste, lisez bien la section 11 du RFC, sur la sécurité. Un programme qui lit du FLAC doit être paranoïaque (comme avec n'importe quel autre format, bien sûr) et se méfier des cas pathologiques. Ainsi, le RFC note qu'on peut facilement créer un fichier FLAC de 49 octets qui, décomprimé, ferait 2 mégaoctets, ce qui pourrait dépasser la mémoire qui avait été réservée. Ce genre de surprises peut arriver à plusieurs endroits. L'annexe D du RFC contient plusieurs fichiers FLAC intéressants (et vous pouvez les retrouver en ligne) et il existe également une collection de fichiers FLAC, dont certains sont délibérement anormaux, pour que vous puissiez tester la robustesse de votre programme. Autre piège (mais lisez toute la section 11, il y en a beaucoup), FLAC permet de mettre des URL dans les fichiers, URL qu'il ne faut évidemment pas déréférencer bêtement.

Ce RFC est également la documentation pour l'enregistrement du type MIME audio/flac (section 12.1).

Pour une analyse technique de la prétention « sans perte » de FLAC, voir cet article de Guillaume Seznec.

Le protocole LISP (qui n'a rien à voir avec le langage de programmation du même nom), vise à résoudre un problème documenté dans le RFC 4984 : les difficultés que rencontre le système de routage de l'Internet devant les pressions imposées par la croissance du réseau et par le désir des utilisateurs de ne pas être lié à un unique fournisseur d'accès. Actuellement, tout changement de routage sur n'importe quel site se propage à tous les autres routeurs de la DFZ. Un tel système ne passe pas réellement à l'échelle (il ne peut pas croitre indéfiniment). LISP propose une solution, dans un ensemble de RFC dont ce RFC 9300 (qui succède au RFC 6830) est le principal. LISP n'est désormais plus considéré comme expérimental et ce nouveau RFC est sur le chemin des normes (Standards Track) mais, en pratique, le projet LISP semble plutôt en panne.

Avant de plonger dans ce RFC, voyons les motivations pour LISP et ses principes essentiels (si vous préférez les lire dans le RFC et pas dans mon article, c'est en section 4 mais la lecture recommandée est le RFC 9299). Aujourd'hui, les adresses IP ont deux rôles, localisation (où suis-je connecté au réseau) et identité (qui suis-je). Une adresse IP est un localisateur car changer de point d'attachement (par exemple parce qu'on change de FAI) vous fait changer d'adresse IP, et c'est un identificateur car c'est ce qui est utilisé par les protocoles de transport comme TCP pour identifier une session en cours : changer d'adresse IP casse les connexions existantes.

Le principal problème de cet approche concerne le routage. Un routage efficace nécessiterait une cohérence entre les adresses et la topologie du réseau, par exemple que deux sites proches sur le réseau aient des adresses proches. Mais on n'a pas cette cohérence actuellement. On notera qu'IPv6 ne résolvait pas ce problème, et délibérement (le cahier des charges d'IPv6 ne prévoyait pas de changer le modèle de routage).

Résultat, les routeurs doivent gérer bien plus de routes que nécessaire, augmentant leur prix (en attendant le jour où, même en payant, on n'arrivera pas à manipuler autant de routes, avec leurs changements fréquents). Le RFC 4984 insistait sur ce problème en affirmant que « The workshop participants believe that routing scalability is the most important problem facing the Internet today and must be solved, although the time frame in which these problems need solutions was not directly specified. »

Cette croissance de la table de routage peut être suivie sur le célèbre site de Geoff Huston. Notez que la taille n'est pas le seul aspect, le rythme de changement (le nombre d'updates BGP par seconde) est au moins aussi important.

LISP vise donc à résoudre ce problème par une technique connue sous le nom de séparation du localisateur et de l'identificateur (son nom, « Locator/ID Separation Protocol », en dérive d'ailleurs, bien qu'il soit loin d'être le seul protocole dans cette catégorie). Au lieu que tous les préfixes IP aillent dans la DFZ, seuls les localisateurs, les RLOC (Routing LOCators) y iront. Les identificateurs, les EID (Endpoint IDentifiers) sont dans un nouveau système, le système de correspondance (mapping, RFC 9301), qui permettra de trouver un RLOC à partir d'un EID. LISP est donc l'application d'un vieux principe de l'informatique : « Tout problème peut être résolu en ajoutant un niveau d'indirection. »

À quoi ressemblent RLOC et EID ? Physiquement, ce sont juste des adresses IP (v4 ou v6), avec une nouvelle sémantique. Le RFC 8060 décrit plus en détail comment représenter les EID.

Par rapport aux autres solutions de séparation de l'identificateur et du localisateur (la plus achevée étant HIP), LISP s'identifie par les points suivants :

• Solution dans le réseau, pas dans les machines terminales. Seuls des routeurs (mais pas tous les routeurs de l'Internet) seront modifiés pour gérer LISP.
• Déployable de manière incrémentale (il n'est pas nécessaire que tout le monde passe à LISP).
• Pas de cryptographie (et donc pas plus de sécurité que l'IP d'aujourd'hui).
• Indépendant de la famille IP utilisée (v4 ou v6).
• Outre une solution au problème du passage à l'échelle du système de routage, LISP se veut aussi utilisable pour la mobilité et la virtualisation de réseaux (imaginez une machine virtuelle migrant d'un centre d'hébergement à un autre sans changer d'identificateur...).

Comment se passe l'envoi d'un paquet avec LISP ? Supposons qu'une machine veuille écrire à www.example.com. Elle utilise le DNS comme aujourd'hui, pour trouver que l'adresse est 2001:db8:110:2::e9 (c'est un EID, un identificateur, mais la machine n'a pas besoin de le savoir, les machines terminales ne connaissent pas LISP et ne savent même pas qu'elles l'utilisent). Elle envoie le paquet à son routeur habituel. À un moment dans le réseau, le paquet va arriver dans un routeur LISP (qui, lui, a été modifié pour gérer LISP). Il va alors chercher le RLOC (le localisateur). Il demande au système de correspondance (l'équivalent LISP du DNS) qui va lui dire « le RLOC de 2001:db8:110:2::e9 est 198.51.100.178 » (notez au passage que RLOC et EID peuvent être des adresses v4 ou v6). (L'information est stockée dans un cache du routeur, pour le prochain paquet.) Le paquet est alors encapsulé dans un paquet LISP qui est transmis en UDP (port 4341) à 198.51.100.178. (En raison de ces deux étapes, correspondance puis encapsulation, LISP fait partie des protocoles nommés Map and Encap.) 198.51.100.178 décapsule et le paquet suit ensuite un chemin normal vers la machine 2001:db8:110:2::e9. Pendant le trajet dans le tunnel, le paquet aura donc deux en-têtes, l'interne (celui placé par la machine d'origine et qui utilise des EID dans les champs « Adresse IP source » et « Adresse IP destination ») et l'externe (celui placé par le routeur d'entrée du tunnel, et qui utilise des RLOC).

Si le système de correspondance avait répondu négativement « Ce n'est pas un EID, je n'ai pas de RLOC pour 2001:db8:110:2::e9 » (Negative map reply) ? Cela aurait voulu dire que le site cible n'utilise pas LISP et, dans ce cas, on lui transmet le paquet par les mécanismes habituels d'IP.

Ainsi, pour prendre le scénario d'usage principal de LISP, un site qui veut être multi-homé n'aura pas besoin de BGP et d'annoncer ses routes dans la DFZ. Il aura ses identificateurs, ses EID, et les paquets entrant ou sortant de son réseau seront encapsulés en LISP (le système de correspondance peut renvoyer plusieurs RLOC pour un EID, avec des préférences différentes, pour faire de l'ingénierie de trafic). Pour les routeurs de la DFZ, ce seront juste des paquets IP ordinaires. Seules les deux extrémités du tunnel sauront que LISP est utilisé.

Le système de correspondance de LISP n'est pas unique : plusieurs choix sont possibles comme ALT (RFC 6836). Comme le DNS, il fonctionne en tirant les informations nécessaires (pas en les poussant vers tout le monde, comme le fait BGP), ce qui devrait lui donner une bonne capacité de croissance. De toute façon, LISP spécifie une interface vers le système de correspondance (RFC 9301) et les différents systèmes ont juste à mettre en œuvre cette interface pour qu'on puisse en changer facilement. Ainsi, ALT pourra être remplacé par un de ses concurrents, CONS, EMACS ou NERD (leurs noms sont des références au langage de programmation). NERD est documenté dans le RFC 6837.

LISP est aujourd'hui essentiellement promu par Cisco, qui avait monté un réseau mondial de test.

Ce RFC est un gros morceau (d'autant plus que d'autres parties de LISP sont dans d'autres RFC). Je ne vais pas le couvrir en entier. Mais quelques points méritent d'être gardés en tête :

• Un paquet dont l'adresse de destination est un EID ne peut être acheminé que via LISP. L'EID n'est pas routé sur l'Internet habituel. (Les EID peuvent être des adresses RFC 1918, par exemple.)
• Pour éviter que la base des EID ne pose les mêmes problèmes de croissance que la DFZ d'aujoud'hui, les EID seront agrégés, mais cela sera fait de manière indépendante de la topologie : si on change de FAI, cette agrégation ne changera pas.

Pour les fanas de format de paquets, la section 5 décrit l'encapsulation. LISP est indépendant de la famille d'adresses, donc on peut avoir un paquet IP où les EID sont IPv4 qui soit tunnelé avec des RLOC IPv6 ou bien le contraire. Devant le paquet normal, LISP va ajouter un en-tête IP standard pour les RLOC, où la source sera l'ITR (routeur d'entrée du tunnel) et la destination l'ETR (routeur de sortie du tunnel), puis un en-tête UDP (l'UDP a davantage de chances de passer les middleboxes que de l'IP mis directement dans l'IP, des protocoles comme QUIC ont le même problème), avec le port de destination à 4341, puis un en-tête spécifique à LISP et enfin le paquet original. Donc, pour résumer :

• En-tête du paquet original (inner header en terminologie LISP) : les adresses IP source et destination sont des identificateurs, des EID,
• En-tête vus par les routeurs situés entre l'ITR et l'ETR (outer header) : les adresses IP source et destination sont des localisateurs, des RLOC.

L'en-tête spécifique à LISP contient notamment (section 5 si vous voulez tout connaître) :

• Cinq bits de contrôle, nommés N, L, E, V et I
• Si le bit N est à 1, un champ Nonce (section 10.1). Il s'agit d'un nombre tiré au hasard : si le destinataire d'un paquet peut le renvoyer, cela prouve qu'il avait reçu le message original (et qu'on parle donc bien au bon destinataire : ce numnique sert à éviter les attaques en aveugle).
• Si le bit L est à 1, un champ Locator Status Bits, qui indique l'état (joignable ou pas) des machines situées sur le site de départ du paquet. (À ne pas utiliser sur l'Internet public, cf. section 4.1.)

Comme toutes les solutions à base de tunnel, LISP va souffrir de la mauvaise gestion de la PMTUD dans l'Internet d'aujourd'hui (cf. RFC 4459), l'en-tête LISP supplémentaire réduisant la MTU (cf. section 7 pour des solutions possibles).

La section 5 décrivait les paquets de données, ceux encapsulant les données envoyées par le site original. La section 6 couvre les paquets de contrôle, utilisés par LISP pour ses propres besoins, notamment le système de correspondance (cf. RFC 9301 pour les détails). On y retrouve l'utilisation d'UDP :

• Map Requests, où le port de destination est 4342,
• Map Replies,
• et quelques autres qui partagent des formats proches.

Il est évidemment essentiel qu'on sache si son correspondant est joignable ou pas. Comment cette « joignabilité » est-elle vérifiée ? La section 6.3 énumère les mécanismes disponibles. Entre autres :

• Les Locator Status Bits où un ITR (le routeur LISP à l'entrée du tunnel) indique si les sites qu'il contrôle sont joignables. Si on souhaite répondre à un message transmis en LISP, c'est une information cruciale. (Ils ne doivent pas être utilisés sur l'Internet public, voir la section 4.1 pour les détails.)
• Les classiques messages ICMP comme Host Unreachable. Comme ils ne sont pas authentifiés, les croire aveuglément est dangereux. Mais les ignorer totalement serait dommage.
• La réception récente d'un message Map Reply est une bonne indication que le site à l'autre bout fonctionne.

Mais on peut aussi tester explicitement, par le mécanisme Echo Nonce de la section 10.1. Le testeur émet un message LISP avec les bits N (numnique présent) et E (écho demandé), met le numnique à une valeur aléatoire (RFC 4086), et envoie le paquet. (La section 4.1 précise toutefois que cela ne doit pas être utilisé sur l'Internet public.) L'ETR à l'autre bout doit normalement renvoyer ce numnique dans son prochain paquet. Notons que cela teste la bidirectionnalité de la connexion. Si on n'obtient pas de réponse, cela peut signifier que la connexion est complètement coupée ou tout simplement qu'elle ne marche que dans un seul sens. Mais, surtout, l'absence de réponse peut indiquer le cas où l'ETR qui reçoit le trafic pour un site n'est pas le même routeur que l'ITR qui génère le trafic sortant. Dans ce cas, l'absence de réponse n'est pas un problème. Enfin, le routeur en face peut tout simplement être configuré pour ignorer les demandes d'écho.

Une autre solution pour tester est donc d'utiliser les messages du système de correspondance EID->RLOC, les Map Request et Map Reply. Ces messages ont un bit P (pour probe) qui indique que le demandeur est intéressé par la joignabilité du site demandé.

LISP impose donc des traitements supplémentaires, par rapport à ceux de l'IP classique. Est-ce que cela ne ralentit pas trop les routeurs ? La section 15 explore le problème et explique pourquoi LISP ne nécessite pas de changement du matériel de forwarding (les ASIC du routeur). La plupart des routeurs ont déjà du code prévu pour gérer des tunnels (encapsuler et décapsuler) rapidement.

Comment sera déployé LISP ? Le RFC 7215 décrit plusieurs scénarios possibles et les détails. Principal problème : combien d'ITR et d'ETR pour un opérateur ? Grâce aux tunnels, on peut n'avoir qu'un seul ITR et un seul ETR pour tout le trafic. Cela poserait évidemment des problèmes de redondance et de performance. Mais avoir beaucoup de xTR peut poser des problèmes d'administration. Si les ITR sont largement automatiques (leur cache des correspondance EID->RLOC est bâti dynamiquement), avoir beaucoup d'ETR risque d'être compliqué à maintenir (car l'ETR doit avoir dans sa configuration une liste des EID qu'il va gérerà).

Un des gros problèmes que pose la séparation de l'identificateur et du localisateur est la sécurité : nouvelles attaques (par exemple contre le système de correspondance), nouveaux pièges (une machine qui utiliserait le vrai RLOC mais mentirait sur l'EID, par exemple). La section 16 du RFC examine les risques théoriquement présents dans LISP, mais lisez aussi les RFC 7835 et RFC 9303.

Comme avec toutes les techniques de tunnel, un émetteur peut facilement tricher sur l'adresse source interne (celle qui sera utilisée après décapsulation par l'ETR). Pour se protéger, un ITR devrait n'encapsuler un paquet que si l'adresse source est un EID qu'il contrôle. Et un ETR ne devrait transmettre un paquet que si la destination est un EID sous sa responsabilité.

Le test de la réversibilité (via les numniques, cf. section 3) est essentiel contre ces risques. Sans ce test, un ETR pirate pourrait par exemple envoyer un Map Reply en réponse aveugle à un Map Request, et le voir accepté, avec des données mensongères (naturellement, l'ITR n'accepte que des Map Replies qui sont en réponse à un Map Request de sa part). Avec ce système de numnique que le récepteur doit mettre dans sa réponse, un attaquant aveugle (qui n'est pas situé sur le chemin des paquets et ne peut donc pas les observer) aura donc peu de chances de réussir à faire accepter ses paquets.

En revanche, un attaquant situé sur le chemin, et qui peut observer les paquets qui passent, a la possibilité de commettre bien plus de dégâts. Mais c'est déjà le cas avec les protocoles actuels (par exemple, les numéros de séquence difficiles à deviner du RFC 6528 ne protègent pas TCP contre des attaquants situés sur le chemin).

Les attaques par déni de service sont évidemment possibles avec LISP : une des précautions recommandées est de limiter le trafic des Map Requests et Map Replies. Autre attaque par déni de service, un ITR peut être victime d'une machine qui essaie de remplir la table des correspondances EID->RLOC du routeur. Il est donc important d'envisager ce cas, par exemple en permettant de garder dans le cache les entrées les plus fréquemment accédées (pour éviter qu'elles ne soient retirées automatiquement pour faire de la place). Mais il n'existe pas de solution miracle contre ce problème d'envahissement de cache.

Le fonctionnement de LISP est schématisé sur ce dessin : Alice a l'identificateur (EID) 2001:db8:1::1 et veut écrire à Bob qui a le 2001:db8:2::42 (dans la plupart des cas, Alice aura trouvé l'adresse de Bob dans le DNS, comme aujourd'hui). Ni Alice, ni Bob n'ont à connaître LISP, chacun croit utiliser de l'IP normal. Alice envoie donc un paquet standard, à destination de 2001:db8:2::42. Mais, sur le trajet, il y a un ITR, un routeur LISP. Celui-ci va chercher (dans le système de correspondance, non montré ici) le RLOC (le localisateur) de Bob (ou, plus exactement, de son site). Une fois qu'il a trouvé 2001:db8:ff::666, il encapsule le paquet derrière un en-tête LISP et envoie ce paquet à l'ETR, l'autre routeur LISP en face, 2001:db8:ff::666. Les routeurs de l'Internet, entre l'ITR et l'ETR, ne connaissent pas LISP non plus et routent ce qui leur semble un paquet IP normal. Arrivé à l'ETR, le paquet est décapsulé et poursuit son chemin par du routage IP classique. Sur tout le schéma, seuls l'ITR et l'ETR sont des nouveautés LISP.

Modifions légèrement le schéma pour y mettre le système de correspondance : On y voir l'ITR demander à son résolveur « Quel est le localisateur de 2001:db8:2::42 ? » et son résolveur lui répondre. Le résolveur avait demandé au serveur qui avait reçu de l'ETR un enregistrement disans « Le localisateur de 2001:db8:2::42 est 2001:db8:ff::666 ». Entre le résolveur et le serveur se trouve le cœur du système de correspondance. LISP en a plusieurs possibles, comme le ALT du RFC 6836.

Où trouve-t-on du code LISP aujourd'hui ?

• Bien sûr dans IOS puisque LISP est l'enfant de Cisco.
• FreeBSD avait OpenLISP, qui semble abandonné (ou intégré dans le système ? Quelqu'un sait ?).
• Pour Linux, je ne connais que LispMob, qui traite un besoin spécifique (la mobilité).
• Il parait qu'un code Cisco mettant en œuvre LISP tourne sur Android.

Comme pour tous les protocoles fondés sur le principe de la séparation de l'identificateur et du localisateur, il est toujours utile, si on veut en comprendre les principes, de (re)lire l'article fondateur de Chiappa, « Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture ». Autres articles à lire :

• Le RFC 9299, une introduction à LISP et ses concepts,
• Un bon résumé de LISP.
• Le premier article pratique sur le protocole. Avec instructions, commandes, et résultat (sur des routeurs Cisco). Parfait pour les ingénieurs qui ont du mal à se taper les RFC LISP mais veulent quand même comprendre comment ça marche. Très détaillé. Le même auteur a d'autres articles sur LISP comme celui expliquant comment tunneler IPv6 sur IPv4.
• Le compte-rendu de la connexion de Facebook à LISP (Facebook a été le premier gros site à sauter le pas mais je ne sais pas si cela fonctionne toujours aujourd'hui).

La section 18 de notre RFC décrit les changements depuis le RFC 6830. Le principal est bien sûr que LISP n'est plus considéré comme expérimental, on peut le déployer sur l'Internet public, modulo les précautions de la section 4.1. Sinon :

• Les trois bits qui étaient réservés dans l'en-tête ont été alloués par le RFC 8061,
• La récolte automatique d'informations de corerspondance entre EID et RLOC (gleaning) est désormais optionnelle,
• Sur la forme, notons que bien des points, notamment le mécanisme de contrôle (et pas seulement d'acheminement de données) ont été déplacés vers le RFC 9301.

La section 4.1 décrit ce qu'il faut faire et ne pas faire lorsqu'on déploie LSIP « en vrai » sur l'Internet public. Quand on n'est plus expérimental, il faut faire attention. Bien des techniques de LISP (comme la mise à jour automatique des données des routeurs juste en regardant un paquet qui passe, le gleaning, clairement dangereux) ne sont sûres que dans un environnement fermé.

Ce court RFC ajoute aux certificats PKIX du RFC 5280 la possibilité de contenir des adresses de courrier électronique dont la partie locale est en Unicode. Et il modifie légèrement les règles pour les noms de domaine en Unicode dans les certificats. Il remplace le RFC 8399, avec peu de changements.

Les certificats sur l'Internet sont normalisés dans le RFC 5280, qui décrit un profil de X.509 nommé PKIX (définir un profil était nécessaire car la norme X.509 est bien trop riche et complexe). Ce RFC 5280 permettait des noms de domaine en Unicode (sections 4.2.1.10 et 7 du RFC 5280) mais il suivait l'ancienne norme IDN, celle des RFC 3490 et suivants. Depuis, les IDN sont normalisés dans le RFC 5890 et suivants, et notre nouveau RFC 9549 modifie très légèrement le RFC 5280 pour s'adapter à cette nouvelle norme de noms de domaines en Unicode. Les noms de domaine dans un certificat peuvent être présents dans les champs Sujet (titulaire du certificat) et Émetteur (AC ayant signé le certificat) mais aussi dans les contraintes sur le nom (une autorité de certification peut être limitée à des noms se terminant en example.com, par exemple).

Notez que, comme avant, ces noms sont exprimés dans le certificat en Punycode (RFC 3492, xn--caf-dma.fr au lieu de café.fr), appelé A-label dans notre RFC. C'est un bon exemple du fait que les limites qui rendaient difficiles d'utiliser des noms de domaine en Unicode n'avaient rien à voir avec le DNS (qui n'a jamais été limité à ASCII, contrairement à ce qu'affirme une légende courante). En fait, le problème venait des applications (comme PKIX), qui ne s'attendaient pas à des noms en Unicode. Un logiciel qui traite des certificats aurait été bien étonné de voir des noms de domaines non-ASCII, et aurait peut-être planté. D'où ce choix du Punycode (A-label) par opposition à la forme plus lisible du U-label.

Nouveauté plus importante du RFC 8399, mis à jour par notre RFC 9549, les adresses de courrier électronique en Unicode (EAI pour Email Address Internationalization). Elles étaient déjà permises par la section 7.5 du RFC 5280, mais seulement pour la partie domaine (à droite du @). Désormais, elles sont également possibles dans la partie locale (à gauche du @). Le RFC 8398 donne tous les détails sur ce sujet.

Reste à savoir quelles AC acceptent Unicode. En 2018, j'avais testé avec Let's Encrypt (avec le client Dehydrated, en mettant le Punycode dans domains.txt) et ça marchait, regardez le certificat de https://www.potamochère.fr/. Le voici, affiché par GnuTLS :

% gnutls-cli www.potamochère.fr
...
- subject `CN=www.xn--potamochre-66a.fr', issuer `CN=R10,O=Let's Encrypt,C=US', serial 0x03a34cfc017b4311da0b21797cd250ebd3c0, RSA key 4096 bits, signed using RSA-SHA256, activated `2024-11-01 05:26:59 UTC', expires `2025-01-30 05:26:58 UTC', pin-sha256="6y…
    

D'autres AC acceptent ces noms en Unicode : Gandi le fait aussi, par exemple. On notera que le célèbre service de test de la qualité des configurations TLS, SSLlabs, gère bien les IDN :

Enfin, le registre du .ru a participé au développement de logiciels pour traiter l'Unicode dans les certificats.

La section 1.2 résume les changements depuis le RFC 8399. Notamment :

• Le RFC 8399 ne les mentionnait pas mais les emojis ne sont pas autorisés dans les noms de domaine (ils appartiennent à la catégorie Unicode So, « Autres symboles », que le RFC 5890 n'inclut pas). Comme le rappelle notre RFC 9549, un nom comme ♚.example ne serait pas légal. Ce point est désormais explicite.
• Si le RFC 8399 prescrivait certains traitements à faire sur la forme Unicode (U-label) des noms, désormais, tout se fait sur la forme en Punycode (A-label, donc xn--potamochre-66a.fr et pas potamochère.fr). Cela permet d'éviter de déclencher certaines failles de sécurité.

Voici une légère mise à jour de la grammaire du langage de description de schéma CDDL (Concise Data Definition Language), originellement normalisé dans le RFC 8610. Pas de gros changement.

Il y avait juste quelques errata à traiter, et des ambiguités concernant notamment les chaines de caractères. Il était devenu nécessaire de modifier l'ABNF. CDDL a été décrit dans le RFC 8610, puis étendu par le RFC 9165. Il vise à décrire un schéma pour des fichiers CBOR ou JSON. Depuis quatre ans qu'il est normalisé, plusieurs erreurs ont été relevées dans la norme. (Dont une, c'est amusant, causée par le traitement du source du RFC, traitement qui avait fait disparaitre accidentellement des barres obliques inversées.)

Donc, notre RFC 9682 modifie l'ABNF qui décrit les littéraux pour les chaines de caractères, ABNF qui était trop laxiste (section 2 du RFC). Il change également la grammaire générale (section 3) pour autoriser (au niveau syntaxique) des schémas vides (ils restent interdits au niveau sémantique). Ainsi, l'ancienne règle :

cddl = S 1*(rule S)
  

devient :

cddl = S *(rule S)        
  

Un RFC sur un format d'image : il décrit le format WebP et enregistre officiellement le type image/webp.

Bon, des images au format WebP, vous en avez forcément vu un peu partout sur le Web. Mais le format n'était pas encore documenté par un organisme de normalisation. C'est désormais fait. WebP s'appuie sur le format RIFF. Plus précisément, RIFF est un cadre générique qui peut se décliner en divers formats. C'est pour cela que les fichiers WebP commencent par les quatre codes ASCII correspondant à "RIFF".

WebP permet de la compression avec perte ou sans perte, et, d'une manière générale, tout ce qu'on attend d'un format graphique. C'est donc un concurrent de JPEG, PNG (RFC 2083), GIF… L'encodage lors de la compression avec perte est celui de VP8 (RFC 6386), produisant des images plus petites que ses prédécesseurs, ce qui est bon pour le réseau. La compression sans perte est faite en LZ77 et Huffman. WebP permet également le stockage de métadonnées codées en EXIF ou en XMP. Ah, et WebP permet des animations.

Cette image, sur un sujet politique qui est toujours d'actualité, est au format WebP :

La section 2 du RFC décrit le format en détail. Les trois premiers champs sont la chaine "RIFF", la taille du fichier en binaire et la chaine "WEBP", chacun sur quatre octets. Affichons ces trois champs :

% dd if=how-do-you-like-it-wrapped.webp bs=4 count=3
RIFFXWEBP
3+0 records in
3+0 records out
12 bytes copied…

La section 3 décrit ensuite le stockage des pixels sans perte.

Comme avec tout format, les logiciels qui lisent les fichiers WebP (qu'on télécharge souvent depuis l'Internet, via des sources pas forcément de confiance) doivent être prudents dans l'analyse des fichiers. Les fichiers peuvent être invalides, par accident ou délibérément, et mener le logiciel négligent à lire en dehors d'un tableau ou déréférencer un pointeur invalide. La paranoïa est recommandée quand on lit ces fichiers. Plusieurs failles ont touché la libwebp, l'implémentation de référence, dont la grave CVE-2023-4863 en 2023 qui avait fait, à juste titre, beaucoup de bruit.

Toujours question sécurité, WebP n'a pas de contenu exécutable (contrairement à, par exemple, TrueType). Mais les métadonnées EXIF ou en XMP peuvent poser des problèmes de sécurité et doivent donc être interprétées avec prudence.

Le type image/webp est désormais dans le registre des types de médias (cf. le formulaire rempli).

Si on regarde des fichiers WebP, on a ce genre d'informations :

% file resolution-dns.webp
resolution-dns.webp: RIFF (little-endian) data, Web/P image

% file --mime-type resolution-dns.webp
resolution-dns.webp: image/webp
   

Pour finir, produisons un peu d'images WebP pour voir. Si on utilise Asymptote, c'est facile :

%  asy -f webp -o resolution-dns.webp resolution-dns.asy
  

On peut aussi convertir depuis les formats existants, ici avec ImageMagick :

% convert -verbose resolution-dns.png resolution-dns.webp
resolution-dns.png PNG 823x508 823x508+0+0 8-bit sRGB 31713B 0.020u 0:00.011
resolution-dns.png=>resolution-dns.webp PNG 823x508 823x508+0+0 8-bit sRGB 16580B 0.040u 0:00.047
  

Si on fait des graphiques depuis ses programmes en Python avec Matplotlib, il suffit, depuis la version 3.6, de :

plot.savefig(fname="test.webp") # No need to indicate the format, it
                                  # is taken from the file extension.
  

(Voir aussi ce beau résultat sur Wikimedia Commons.)

La fragmentation d'Internet est un sujet complexe, et souvent mal traité. Ce court livre fait le point sur les différentes questions que soulève ce débat et d'abord « qu'est-ce que c'est que la fragmentation ? » J'en recommande la lecture.

Le terme de fragmentation a en effet souvent été utilisé dans un but politique. Des influenceurs étatsuniens ont dit que le RGPD (ou le DSA), avec son application extra-territoriale, menait à une fragmentation de l'Internet. D'autres influenceurs étatsuniens (ou les mêmes) dénoncent toute activité de souveraineté numérique (imposer le stockage des données dans le pays, imposer que les échanges entre entités du pays restent dans le pays, etc) comme de la fragmentation. On entend souvent dire que les Chinois ou les Russes auraient « leur propre Internet » (ce qui n'a aucun sens). On se demande souvent si les gens qui répètent avec gourmandise qu'il y a fragmentation de l'Internet avec les actions russes ou chinoises le déplorent, ou bien s'ils voudraient que d'autres pays fassent pareil… Enfin, le débat est souvent marqué par l'hypocrisie comme lorsque les USA dénoncent le fait que le gouvernement chinois veuille empêcher ses citoyens d'aller sur Facebook alors que lui-même fait tout pour bloquer TikTok. En paraphrasant OSS 117, on pourrait dire « non, mais la fragmentation, c'est seulement quand les gens ont des manteaux gris et qu'il fait froid ».

Bref, le débat est mal parti. D'où l'importance de ce livre, qui est tiré d'un rapport au Parlement européen des mêmes auteurs, et qui étudie sérieusement les différents aspects de la question.

Déjà, première difficulté, définir la fragmentation. Est-ce lorsque une machine ne peut plus envoyer un paquet IP à une autre ? (La traduction d'adresses est-elle un facteur de fragmentation ?) Est-ce lorsque le résolveur DNS par défaut ne résout pas certains noms ? (Et si on peut en changer ?) Est-ce quand les Chinois n'utilisent pas les mêmes réseaux sociaux ou moteurs de recherche que nous ? (Ne riez pas, j'ai déjà entendu cette affirmation.) Bien des participant·es au début ne connaissent pas le B.A. BA du modèle en couches et n'essaient même pas de définir rigoureusement la fragmentation. Les auteur·es du livre s'attachent à examiner les définitions possibles. Non, ielles ne fournissent pas « la bonne définition », le problème est trop complexe pour cela. Il est sûr que tout·e utilisateurice de l'Internet ne voit pas la même chose et n'a pas le même vécu. Mais enfermer cette observation évidente dans une définition rigoureuse reste difficile.

D'un côté, disent les auteure·es, il y a bien des tendances centrifuges. De l'autre, non, l'Internet n'est pas fragmenté, malgré les affirmations de ceux qui tentent des prophéties auto-réalisatrices (comme le notent les auteur·es, le thème de la fragmentation et l'utilisation de termes journalistiques comme « splinternet » est souvent simplement une arme rhétorique). Mais est-ce que cela durera ?

Le livre détaille l'action des États qui pousse à la fragmentation, le jeu des lois du marché qui peut mener à la création de silos fermés (la fameuse « minitélisation de l'Internet »), etc.

Bon, une critique, quand même. Tout débat sur la politique Internet est forcément complexe car il faut à la fois comprendre la politique et comprendre Internet. Et, s'agissant de l'Internet, des faits de base (comme le pourcentage d'utilisateurs qui utilisent un résolveur DNS public) sont souvent difficiles à obtenir. Néanmoins, prétendre que dix sociétés résolvent la moitié des requêtes DNS au niveau mondial est impossible à croire. Le chiffre, cité p. 73, est tiré d'un article grossièrement anti-DoH qui ne cite pas ses sources. (Pour voir à quel point ce chiffre est invraisemblable, pensez simplement que toutes les études montrent que les résolveurs DNS publics sont une minorité des usages, et surtout que cela dépend des pays, les Chinois n'utilisant pas les mêmes que les Français et ielles sont nombreux.) L'usage de chiffres « au doigt mouillé » est malheureusement fréquent dans les débats de politique Internet.

Mais, bon, je l'ai dit, la question est très complexe, les données souvent dures à obtenir et cette critique ne doit pas vous empêcher d'apprendre tout sur le débat « fragmentation » dans cet excellent livre. Et rappelez-vous, l'avenir de l'Internet dépend aussi de vous.

Que doit faire un routeur BGP lorsque le pair en face ne traite manifestement plus ses messages ? Ce n'était pas précisé avant mais la réponse est évidente : raccrocher (mettre fin à la communication).

Un problème classique lors d'une connexion réseau, par exemple sur TCP, est de détecter si la machine en face est toujours là. Par défaut, TCP ne fournit pas ce service : s'il n'y a aucun trafic, vous ne pouvez pas savoir si votre partenaire est mort ou simplement s'il n'a rien à dire. Une coupure de réseau, par exemple, ne sera pas détectée tant que vous n'avez pas de trafic à transmettre (avec attente d'une réponse). Et BGP ne transmet que les changements donc l'absence de trafic ne signale pas forcément un problème. Il existe des solutions, comme d'envoyer périodiquement des messages même quand on n'a rien à dire (RFC 4271, section 4.4), mais aucune n'est parfaite : un programme qui utilise TCP ne sait typiquement pas immédiatement si ses messages sont vraiment partis (et l'alarme actuelle ne couvre que la réception des messages, pas leur envoi). Et BGP n'a pas de fonction « ping », qui exigerait une réponse.

Quand la coupure est franche et détectée, aucun problème, la session BGP (RFC 4271) s'arrête et les routes correspondantes sont retirées de la table de routage. Mais ce RFC traite le cas de où le routeur BGP d'en face a un problème mais qu'on ne détecte pas. Un exemple : si ce routeur en face a complètement fermé sa fenêtre TCP de réception (RFC 9293, notamment la section 3.8.6), on ne pourra pas lui envoyer de messages, mais la session BGP ne sera pas coupée et les paquets continueront à être transmis selon des annonces de routage dépassées, alors qu'ils finiront peut-être dans un trou noir (le problème des « zombies BGP »).

La solution (section 3 de notre RFC) est de modifier l'automate de BGP (RFC 4271, section 8), en ajoutant une alarme (RFC 4271, section 10), SendHoldTimer. Quand elle expire, on coupe la connexion TCP et on retire les routes qu'avait annoncé le pair dont on n'a plus de nouvelles. Le RFC recommande une configuration par défaut de huit minutes de patience avant de déclencher l'alarme.

L'erreur « Send Hold Timer Expired » est désormais dans le registre IANA des erreurs BGP et tcpdump sait l'afficher. Il existe plusieurs mises en œuvre de ce RFC :

• Celle d'OpenBGPD (son source),
• Celle de FRRouting (son source),
• Celle de BIRD (son source).

Si les processus IETF vous passionnent, il y a une documentation des discussions autour de ce RFC.

On a souvent envie de faire tourner des programmes à soi dans le noyau du système d'exploitation, par exemple à des fins de débogage ou d'observation du système. Cela soulève plein de problèmes (programmer dans le noyau est délicat) et la technique eBPF permet, depuis de nombreuses années, de le faire avec moins de risques. Ce RFC spécifie le jeu d'instructions eBPF. Programmeureuses en langage d'assemblage, ce RFC est pour vous.

eBPF désigne ici un jeu d'instructions (comme ARM ou RISC-V). Programmer en eBPF, c'est donc programmer en langage d'assemblage et, en général, on ne le fait pas soi-même, on écrit dans un langage de plus haut niveau (non spécifié ici mais c'est souvent un sous-ensemble de C) et on confie à un compilateur le soin de générer les instructions. Ce jeu d'instructions a plusieurs particularités. Notamment, il est délibérément limité, puisque toute bogue dans le noyau est particulièrement sérieuse, pouvant planter la machine ou pire, permettre son piratage. Vous ne pouvez pas faire de boucles générales, par exemple. eBPF est surtout répandu dans le monde Linux (et c'est là où vous trouverez beaucoup de ressources) où il est une alternative aux modules chargés dans le noyau. Pas mal du code réseau d'Android est ainsi en eBPF. Normalisé ici, eBPF peut être mis en œuvre sur d'autres noyaux (il tourne sur Windows, par exemple). Le monde eBPF est très riche, il y a plein de logiciels (pas toujours faciles à utiliser), plein de tutoriels (pas toujours à jour et qui ne correspondent pas toujours à votre système d'exploitation) mais cet article se focalise sur le sujet du RFC : le jeu d'instructions.

On trouve de nombreux exemples d'utilisation en production par exemple le répartiteur de charge Katran chez Facebook, via lequel vous êtes certainement passé, si vous utilisez Facebook. En plus expérimental, j'ai trouvé amusant qu'on puisse modifier les réponses DNS en eBPF.

Passons tout de suite à la description de ce jeu d'instructions (ISA = Instruction Set Architecture). D'abord, les types (section 2.1) : u32 est un entier non signé sur 32 bits, s16, un signé sur 16 bits, etc. eBPF fournit des fonctions de conversions utiles (section 2.2) comme be16 qui convertit en gros boutien (le RFC cite IEN137…). Au passage, une mise en œuvre d'eBPF n'est pas obligée de tout fournir (section 2.4). La norme décrit des groupes de conformité et une implémentation d'eBPF doit lister quels groupes elle met en œuvre. Le groupe base32 (qui n'a rien à voir avec le Base32 du RFC 4648) est le minimum requis dans tous les cas. Par exemple, divmul32 ajoute multiplication et division. Tous ces groupes figurent dans un registre IANA.

Les instructions eBPF sont encodées en 64 ou 128 bits (section 3). On y trouve les instructions classiques de tout jeu, les opérations arithmétiques (comme ADD), logiques (comme AND), les sauts (JA, JEQ et autrs), qui se font toujours vers l'avant, pour, je suppose, ne pas permettre de boucles (souvenez-vous du problème de l'arrêt, qui n'a pas de solution avec un jeu d'instructions plus étendu), l'appel de fonction, etc.

En parlant de fonctions, eBPF ne peut pas appeler n'importe quelle fonction. Il y a deux sortes de fonctions utilisables, les fonctions d'aide (section 4.3.1), pré-définies par la plateforme utilisée, et non normalisées (pour celles de Linux, voir la documentation, qui est sous Documentation/bpf si vous avez les sources du noyau). Il y a aussi les fonctions locales (section 4.3.2), définies par le programme eBPF.

Il y a enfin des instructions pour lire et écrire dans la mémoire (LD, ST, etc). Pour mémoriser plus facilement, eBPF utilise des dictionnaires (maps, cf. section 5.4.1).

La section 6 concerne la sécurité, un point évidemment crucial puisque les programmes eBPF tournent dans le noyau, où les erreurs ne pardonnent pas. Un programme eBPF malveillant peut provoquer de nombreux dégâts. C'est pour cela que, sur Linux, seul root peut charger un tel programme dans le noyau. Le RFC recommande de faire tourner ces programmes dans un environnement limité (bac à sable), de limiter les ressources dont ils disposent et de faire tourner des vérifications sur le programme avant son exécution (par exemple, sur Linux, regardez cette documentation ou bien l'article « Simple and Precise Static Analysis of Untrusted Linux Kernel Extensions »).

Enfin, section 7, les registres (pas les registres du processeur, ceux où on enregistre les codes utilisés). Deux registres IANA sont créés, celui des groupes de conformité et celui du jeu d'instructions. L'annexe A du RFC donne les valeurs actuelles. Les registres sont extensibles et la politique d'enregistrement est « Spécification nécessaire » et « Examen par un expert », cf. RFC 8126. (J'avoue ne pas savoir pourquoi, si les opcodes sont enregistrés, les mnémoniques ne le sont pas, cela rend les registres difficiles à lire.)

Un peu d'histoire, au passage. eBPF est dérivé de BPF, ce qui voulait dire Berkeley Packet Filter, et était spécifique au filtrage des paquets réseau. Cet usage a été notamment popularisé par tcpdump. D'ailleurs, ce programme a une option pour afficher le code BPF produit :

% sudo tcpdump -d port 53
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 10
(002) ldb      [20]
(003) jeq      #0x84            jt 6    jf 4
(004) jeq      #0x6             jt 6    jf 5
(005) jeq      #0x11            jt 6    jf 23
(006) ldh      [54]
…
(021) jeq      #0x35            jt 22   jf 23
(022) ret      #262144
(023) ret      #0

  

Si vous voulez vous mettre à eBPF (attention, la courbe d'apprentissage va être raide), man 4 bpf est utile. Typiquement, vous écrirez vos programmes dans un sous-ensemble de C et vous compilerez en eBPF, par exemple avec clang, après avoir installé tous les outils et bibliothèques nécessaires (il faut souvent des versions assez récentes) :

% cat count.c
…
int count_packets(struct __sk_buff *skb) {
    __u32 key = 0;
    __u64 *counter;

    counter = bpf_map_lookup_elem(&pkt_counter, &key);
    if (counter) {
        (*counter)++;
    }

    return 0;
}
…

% clang  -target bpf -c count.c

% file count.o
count.o: ELF 64-bit LSB relocatable, eBPF, version 1 (SYSV), not stripped

% objdump -d count.o
…
0000000000000000 <count_packets>:
   0:	7b 1a f8 ff 00 00 00 00 	stxdw [%r10-8],%r1
   8:	b7 01 00 00 00 00 00 00 	mov %r1,0
  10:	63 1a f4 ff 00 00 00 00 	stxw [%r10-12],%r1
  18:	18 01 00 00 00 00 00 00 	lddw %r1,0
  20:	00 00 00 00 00 00 00 00 
  28:	bf a2 00 00 00 00 00 00 	mov %r2,%r10
  30:	07 02 00 00 f4 ff ff ff 	add %r2,-12

  

(Notez l'utilisation du désassembleur objdump.) Vous pouvez alors charger le code eBPF dans votre noyau, par exemple avec bpftool (et souvent admirer de beaux messages d'erreur comme « libbpf: elf: legacy map definitions in 'maps' section are not supported by libbpf v1.0+ »). Si tout fonctionne, votre code eBPF sera appelé par le noyau lors d'événements particuliers que vous avez indiqués (par exemple la création d'un processus, ou bien l'arrivée d'un paquet par le réseau) et fera alors ce que vous avez programmé. Comme me le fait remarquer Pierre Lebeaupin, il y a une bogue dans le source ci-dessus : l'incrémentation du compteur n'est pas atomique et donc, si on a plusieurs CPU, on risque de perdre certaines incrémentations. La solution de ce problème est laissé à la lectrice.

Un exemple d'utilisation d'eBPF pour observer ce que fait le noyau (ici avec un outil qui fait partie de bcc), on regarde les exec :

% sudo /usr/sbin/execsnoop-bpfcc
PCOMM            PID     PPID    RET ARGS
check_disk       389622  1628      0 /usr/lib/nagios/plugins/check_disk -c 10% -w 20% -X none -X tmpfs -X sysfs -X proc -X configfs -X devtmpfs -X devfs -X 
check_disk       389623  1628      0 /usr/lib/nagios/plugins/check_disk -c 10% -w 20% -X none -X tmpfs -X sysfs -X proc -X configfs -X devtmpfs -X devfs -X 
check_swap       389624  1628      0 /usr/lib/nagios/plugins/check_swap -c 25% -w 50%
check_procs      389625  1628      0 /usr/lib/nagios/plugins/check_procs -c 400 -w 250
ps               389627  389625    0 /bin/ps axwwo stat uid pid ppid vsz rss pcpu etime comm args
sh               389632  389631    0 /bin/sh -c   [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi
sessionclean     389633  1         0 /usr/lib/php/sessionclean
sort             389635  389633    0 /usr/bin/sort -rn -t: -k2,2
phpquery         389638  389634    0 /usr/sbin/phpquery -V
expr             389639  389638    0 /usr/bin/expr 2 - 1
sort             389642  389638    0 /usr/bin/sort -rn

Le code eBPF est interprété par une machine virtuelle ou bien traduit à la volée en code natif.

Même ChatGPT peut écrire de l'eBPF (les tours de Hanoi et un serveur DNS).

De nombreux exemples se trouvent dans le répertoire samples/bpf des sources du noyau Linux. (Le fichier README.rst explique comment compiler mais seulement dans le cadre de la compilation d'un noyau. En gros, c'est make menuconfig , cd samples/bpf puis make -i.) Un bon exemple, relativement simple, pour commencer avec le réseau est tcp_clamp_kern.c.

Si vous préférez travailler en Go (là aussi, avec un Go récent…), il existe un bon projet. Si vous suivez bien la documentation, vous pourrez compiler des programmes et les charger :

% go mod init ebpf-test
% go mod tidy
% go get github.com/cilium/ebpf/cmd/bpf2go
% go generate
% go build 
% sudo ./ebpf-test
2024/08/20 15:21:43 Counting incoming packets on veth0..
…
2024/08/20 15:22:03 Received 25 packets
2024/08/20 15:22:04 Received 26 packets
2024/08/20 15:22:05 Received 27 packets 
2024/08/20 15:22:06 Received 502 packets    <- ping -f
2024/08/20 15:22:07 Received 57683 packets
2024/08/20 15:22:08 Received 75237 packets
^C2024/08/20 15:22:09 Received signal, exiting..

Vous trouverez beaucoup de ressources eBPF sur https://ebpf.io/. Et si vous voulez plonger dans les détails précis des choix de conception d'eBPF, je recommande ce document.

Ce RFC avait fait l'objet de pas mal de débats à l'IETF car, normalement, l'IETF ne normalise pas de langages de programmation ou de jeux d'instructions. (La première réunion était à l'IETF 116 en mars 2023 donc c'est quand même allé assez vite.)

Ce nouveau RFC documente un format déjà ancien et largement déployé, TZif, un format de description des fuseaux horaires. Il définit également des types MIME pour ce format, application/tzif et application/tzif-leap. Il remplace le premier RFC de normalisation de ce format, le RFC 8536, mais il y a très peu de changements. Bienvenue donc à la version 4 du format, spécifiée dans ce RFC.

Ce format existe depuis quarante ans (et a pas mal évolué pendant ce temps) mais n'avait apparemment jamais fait l'objet d'une normalisation formelle avant le RFC 8536 en 2019. La connaissance des fuseaux horaires est indispensable à toute application qui va manipuler des dates, par exemple un agenda. Un fuseau horaire se définit par un décalage par rapport à UTC, les informations sur l'heure d'été, des abréviations pour désigner ce fuseau (comme CET pour l'heure de l'Europe dite « centrale ») et peut-être également des informations sur les secondes intercalaires. Le format iCalendar du RFC 5545 est un exemple de format décrivant les fuseaux horaires. TZif, qui fait l'objet de ce RFC, en est un autre. Contrairement à iCalendar, c'est un format binaire.

TZif vient à l'origine du monde Unix et est apparu dans les années 1980, quand le développement de l'Internet, qui connecte des machines situées dans des fuseaux horaires différents, a nécessité que les machines aient une meilleure compréhension de la date et de l'heure. Un exemple de source faisant autorité sur les fuseaux horaires est la base de l'IANA décrite dans le RFC 6557 et dont l'usage est documenté à l'IANA. Pour la récupérer, voir par exemple le RFC 7808.

La section 2 de notre RFC décrit la terminologie du domaine :

• Temps Universel Coordonné (UTC est le sigle officiel) : la base du temps légal. Par exemple, en hiver, la France métropolitaine est en UTC + 1. (GMT n'est utilisé que par les nostalgiques de l'Empire britannique.)
• Heure d'été (le terme français est incorrect, l'anglais DST - Daylight Saving Time est plus exact) : le décalage ajouté ou retiré à certaines périodes, pour que les activités humaines, et donc la consommation d'énergie, se fassent à des moments plus appropriés (cette idée est responsable d'une grande partie de la complexité des fuseaux horaires).
• Temps Atomique International (TAI) : contrairement à UTC, qui suit à peu près le soleil, TAI est déconnecté des phénomènes astronomiques. Cela lui donne des propriétés intéressantes, comme la prédictibilité (alors qu'on ne peut pas savoir à l'avance quelle sera l'heure UTC dans un milliard de secondes) et la monotonie (jamais de sauts, jamais de retour en arrière, ce qui peut arriver à UTC). Cela en fait un bon mécanisme pour les ordinateurs, mais moins bon pour les humains qui veulent organiser un pique-nique. Actuellement, il y a 37 secondes de décalage entre TAI et UTC.
• Secondes intercalaires : secondes ajoutées de temps en temps à UTC pour compenser les variations de la rotation de la Terre.
• Correction des secondes intercalaires : TAI - UTC - 10 (lisez le RFC pour savoir pourquoi 10). Actuellement 27 secondes.
• Heure locale : l'heure légale en un endroit donné. La différence avec UTC peut varier selon la période de l'année, en raison de l'heure d'été. En anglais, on dit aussi souvent « le temps au mur » (wall time) par référence à une horloge accrochée au mur. Quand on demande l'heure à M. Toutlemonde, il donne cette heure locale, jamais UTC ou TAI ou le temps Unix.
• Epoch : le point à partir duquel on compte le temps. Pour Posix, c'est le 1 janvier 1970 à 00h00 UTC.
• Temps standard : la date et heure « de base » d'un fuseau horaire, sans tenir compte de l'heure d'été. En France métropolitaine, c'est UTC+1.
• Base de données sur les fuseaux horaires : l'ensemble des informations sur les fuseaux horaires (cf. par exemple RFC 7808). Le format décrit dans ce RFC est un des formats possibles pour une telle base de données.
• Temps universel : depuis 1960, c'est équivalent à UTC, mais le RFC préfère utiliser UT.
• Temps Unix : c'est ce qui est renvoyé par la fonction time(), à savoir le nombre de secondes depuis l'epoch, donc depuis le 1 janvier 1970. Il ne tient pas compte des secondes intercalaires, donc il existe aussi un « temps Unix avec secondes intercalaires » (avertissement : tout ce qui touche au temps et aux calendriers est compliqué). C'est ce dernier qui est utilisé dans le format TZif, pour indiquer les dates et heures des moments où se fait une transition entre heure d'hiver et heure d'été.

La section 3 de notre RFC décrit le format lui-même. Un fichier TZif est composé d'un en-tête (taille fixe de 44 octets) indiquant entre autres le numéro de version de TZif. La version actuelle est 4. Ensuite, on trouve les données. Dans la version 1 de TZif, le bloc de données indiquait les dates de début et de fin des passages à l'heure d'été sur 32 bits, ce qui les limitait aux dates situées entre 1901 et 2038. Les versions ultérieures de TZif sont passées à 64 bits, ce qui permet de tenir environ 292 milliards d'années mais le bloc de données de la version 1 reste présent, au cas où il traine encore des logiciels ne comprenant que la version 1. Notez que ces 64 bits permettent de représenter des dates antérieures au Big Bang, mais certains logiciels ont du mal avec des valeurs situées trop loin dans le passé.

Les versions 2, 3 et 4 ont un second en-tête de 44 octets, et un bloc de données à elles. Les vieux logiciels arrêtent la lecture après le premier bloc de données et ne sont donc normalement pas gênés par cet en-tête et ce bloc supplémentaires. Les logiciels récents peuvent sauter le bloc de données de la version 1, qui ne les intéresse a priori pas (voir section 4 et annexe A). C'est au créateur du fichier de vérifier que les blocs de données destinés aux différentes versions sont raisonnablement synchrones, en tout cas pour les dates antérieures à 2038.

Nouveauté apparue avec la version 2, il y a aussi un pied de page à la fin. Les entiers sont stockés en gros boutien, et en complément à deux. L'en-tête commence par la chaîne magique « TZif » (U+0054 U+005A U+0069 U+0066), et comprend la longueur du bloc de données (qui dépend du nombre de transitions, de secondes intercalaires et d'autres informations à indiquer). Le bloc de données contient la liste des transitions, le décalage avec UT, le nom du fuseau horaire, la liste des secondes intercalaires, etc. Vu par le mode hexadécimal d'Emacs, voici le début d'un fichier Tzif version 2 (pris sur une Ubuntu, dans /usr/share/zoneinfo/Europe/Paris). On voit bien la chaîne magique, puis le numéro de version, et le début du bloc de données :

00000000: 545a 6966 3200 0000 0000 0000 0000 0000  TZif2...........
00000010: 0000 0000 0000 000d 0000 000d 0000 0000  ................
00000020: 0000 00b8 0000 000d 0000 001f 8000 0000  ................
00000030: 9160 508b 9b47 78f0 9bd7 2c70 9cbc 9170  .`P..Gx...,p...p
00000040: 9dc0 48f0 9e89 fe70 9fa0 2af0 a060 a5f0  ..H....p..*..`..
...
    

Avec od, ça donnerait :

% od -x -a /usr/share/zoneinfo/Europe/Paris
0000000    5a54    6669    0032    0000    0000    0000    0000    0000
          T   Z   i   f   2 nul nul nul nul nul nul nul nul nul nul nul
0000020    0000    0000    0000    0d00    0000    0d00    0000    0000
        nul nul nul nul nul nul nul  cr nul nul nul  cr nul nul nul nul
0000040    0000    b800    0000    0d00    0000    1f00    0080    0000
        nul nul nul   8 nul nul nul  cr nul nul nul  us nul nul nul nul
0000060    6091    8b50    479b    f078    d79b    702c    bc9c    7091
        dc1   `   P  vt esc   G   x   p esc   W   ,   p  fs   < dc1   p
...

    

Des exemples détaillés et commentés de fichiers TZif figurent en annexe B. À lire si vous voulez vraiment comprendre les détails du format.

Le pied de page indique notamment les extensions à la variable d'environnement TZ. Toujours avec le mode hexadécimal d'Emacs, ça donne :

00000b80: 4345 542d 3143 4553 542c 4d33 2e35 2e30  CET-1CEST,M3.5.0
00000b90: 2c4d 3130 2e35 2e30 2f33 0a              ,M10.5.0/3.
    

On a vu que le format TZif avait une histoire longue et compliquée. La section 4 du RFC est entièrement consacrée aux problèmes d'interopérabilité, liés à la coexistence de plusieurs versions du format, et de beaucoup de logiciels différents. Le RFC conseille (sections 4 et 5) :

• De ne plus générer de fichiers suivant la version 1, qui ne marchera de toute façon plus après 2038.
• Les logiciels qui en sont restés à la version 1 doivent faire attention à arrêter leur lecture après le premier bloc (dont la longueur figure dans l'en-tête).
• La version 4 n'apporte pas beaucoup par rapport à la 2 et à la 3 et donc, sauf si on utilise les nouveautés spécifiques de la 4, il est recommandé de produire plutôt des fichiers conformes à la version 2 ou 3.
• Un fichier TZif transmis via l'Internet devrait être étiqueté application/tzif-leap ou application/tzif (s'il n'indique pas les secondes intercalaires). Ces types MIME sont désormais dans le registre officiel (cf. section 9 du RFC).

L'annexe A du RFC en rajoute, tenant compte de l'expérience accumulée ; par exemple, certains lecteurs de TZif n'acceptent pas les noms de fuseaux horaires contenant des caractères non-ASCII et il peut donc être prudent de ne pas utiliser ces caractères. Plus gênant, il existe des lecteurs assez bêtes pour planter lorsque des temps sont négatifs. Or, les entiers utilisant dans TZif sont signés, afin de pouvoir représenter les moments antérieurs à l'epoch. Donc, attention si vous avez besoin de données avant le premier janvier 1970, cela perturbera certains logiciels bogués.

En parlant des noms de fuseaux horaires, le RFC rappelle (section 5) que le sigle utilisé dans le fichier Tzif (comme « CET ») est en anglais et que, si on veut le traduire, cela doit être fait dans l'application, pas dans le fichier. Le RFC donne comme exemple CST, qui peut être présenté comme « HNC », pour « Heure Normale du Centre ».

Autre piège avec ces sigles utilisés pour nommer les fuseaux horaires : ils sont ambigus. PST peut être la côte Ouest des USA mais aussi l'heure du Pakistan ou des Philippines.

La section 7 du RFC donne quelques conseils de sécurité :

• L'en-tête indique la taille des données mais le programme qui lit le fichier doit vérifier que ces indications sont correctes, et n'envoient pas au-delà de la fin du fichier.
• TZif, en lui-même, n'a pas de mécanisme de protection de l'intégrité, encore moins de mécanisme de signature. Il faut fournir ces services extérieurement (par exemple avec curl, en récupérant via HTTPS).

Enfin, l'annexe C du RFC liste les changements depuis le RFC 8536, changements qui mènent à cette nouvelle version, la 4. Rien de crucial mais :

• Formalisation de l'ancienne convention comme quoi un décalage de « - 0 » avec UTC indique qu'on ne connait pas le vrai décalage.
• Correction de plusieurs erreurs.

Une bonne liste de logiciels traitant ce format figure à l'IANA.

L'IETF, l'organisation qui normalise les protocoles de l'Internet a toujours prôné le pragmatisme et le réalisme : ce n'est pas tout d'écrire des normes, il faut encore qu'elles fonctionnent en vrai. Un des outils pour cela est le hackathon qui se déroule traditionnellement le week-end avant les réunions physiques de l'IETF. Ce RFC, écrit par le responsable de ces hackathons, décrit l'organisation de ces événements.

La salle (en cours d'installation) du hackathon à Yokohama en 2023 :

Paradoxalement, alors que cette ambition de réalisme (« we believe in rough consensus and running code ») est ancienne à l'IETF, les hackathons sont relativement récents. Le premier était en 2015 à Dallas. Mais les hackathons font désormais partie de la culture IETF et on n'imagine plus de réunion sans eux. Ils accueillent désormais systématiquement plusieurs centaines de participant·es (cf. section 6 du RFC). (Mon premier était à Chicago.) Au passage, si vous êtes programmeur·se et que vous allez à une réunion IETF, ne ratez pas le hackathon, il en vaut la peine. Le prochain commence ce samedi, le 2 novembre 2024, à Dublin.

Donc, le but du hackathon à l'IETF (section 1 du RFC) est de tester les normes en cours d'élaboration, de voir si la future spécification est claire et réaliste, et de faire en sorte que les gens qui écrivent les normes (qui ne sont pas forcément des développeur·ses) interagissent avec ceux et celles qui mettent en œuvre les normes. (Cela peut paraitre étonnant, mais beaucoup de SDO ne fonctionnent pas comme cela ; la norme est écrite par des gens qui sont très loin du terrain et qui se moquent du caractère réaliste et effectif de leurs textes.) Le code qui tourne est souvent plus significatif qu'une opinion exprimée pendant la réunion. Et le hackathon est aussi l'occasion de travailler en commun (surtout si on est présent·e physiquement), ce qui fait avancer les projets.

Ah, et puisqu'on parle de collaboration, contrairement à certains hackathons, ceux de l'IETF n'ont plus aucune forme de compétition : pas de classement, pas de prix. (Voir la section 7.6 sur le rôle qu'avaient les juges de la compétition et pourquoi cela a été vite supprimé.) En outre, la plupart du code écrit pendant les hackathons est sous une licence libre (la principale exception concerne les gens qui ont modifié un logiciel privateur, par exemple le code de certains routeurs). Du point de vue « juridique », notez que le hackathon est un événement de l'IETF et donc soumis aux règles IETF (voir aussi la section 5.3).

Les hackathons de l'IETF sont gratuits (et il n'est pas forcément nécessaire de payer son voyage, on peut le faire à distance, voir plus loin) et ouverts à tous (cf. section 5.3). On s'inscrit en ligne puis on y va. Si vous êtes débutant·e, ne vous inquiétez pas, on a tous été débutant·es et les hackathons sont justement l'occasion de mêler étudiant·es, expert·es, etc. Une large participation est encouragée.

Comment organise t-on un tel événement ? Charles Eckel, l'auteur du RFC, est pour l'instant le pilier de ces hackathons. Le RFC a été écrit, entre autres, pour transmettre son expérience et permette à d'autres de le seconder ou de lui succéder. La section 2 du RFC détaille les choix effectués. Le hackathon se tient le week-end pour faciliter la participation des gens qui travaillent, notamment de ceux et celles qui ne viennent pas à la réunion IETF la semaine suivante. Et puis ça renforce le côté informel.

Questions horaires, le hackathon de l'IETF n'essaie pas de faire travailler les gens 24 heures sur 24 tout le week-end. La majorité des participant·es au hackathon viennent à l'IETF ensuite et doivent donc rester frai·ches. Le hackathon dure typiquement le samedi de 09:00 à 22:00 et le dimanche de 09:00 à 16:00 (il y a déjà des réunions IETF le dimanche en fin d'après-midi). Si des gens veulent travailler toute la nuit, ielles doivent le faire dans leur chambre.

La nourriture est fournie sur place pour éviter qu'on doive sortir (mais on a évidemment le droit de sortir, les participant·es ne sont pas attaché·es et peuvent estimer plus important d'aller discuter avec d'autres participant·es en dehors du hackathon). Et, comme le note le RFC, c'est une motivation supplémentaire pour faire venir les gens (on mange bien).

Et pour les gens qui sont à distance ? Le problème avait commencé à se poser pour la réunion IETF 107 prévue à Vancouver et annulée au dernier moment pour cause de Covid. Il y avait eu un effort pour maintenir un hackathon en distanciel mais cela n'avait pas intéressé grand'monde. (Un des plus gros problèmes du distanciel est le décalage horaire. Les gens qui n'étaient pas en PST n'avaient montré aucun enthousiasme pour le hackathon.) Cela s'est mieux passé par la suite, avec des réunions entièrement en ligne pendant la pandémie. Aujourd'hui, les réunions ont repris en présentiel mais une partie des participant·es, aussi bien à l'IETF qu'au hackathon, sont à distance. (Mon opinion personnelle est que c'est peu utile ; l'intérêt du hackathon est la collaboration intense avec les gens qui sont juste là. En travaillant à distance, on perd cette collaboration. Autant travailler tout seul dans son coin.) Une approche intermédiaire, très utilisée à Maurice, est d'avoir une réunion en présentiel locale, où les gens travaillent à distance sur le hackathon. Cela permet de garder un côté collectif sympa.

Tout cela (à commencer par les repas, et bien sûr la salle, mais elle est parfois incluse dans le contrat global de l'IETF pour sa réunion) coûte de l'argent. La section 3 décrit les sources de financement, qui permettent de garder le hackathon gratuit pour les participant·es. Il y a, comme souvent dans les conférences techniques, des sponsors. (Pour le prochain hackathon, ce seront Ericsson, Meta et l'ICANN.) Mais il y a aussi un financement par l'IETF elle-même (car on ne trouve pas toujours des sponsors). Le RFC précise même quels repas seront sacrifiés s'il n'y a pas assez d'argent (le diner du samedi est considéré comme moins important que les déjeuners, car les participant·es pourront toujours diner en rentrant).

Ah, et les T-shirts ? Pas de hackathon sans T-shirt. Le RFC donne des statistiques intéressantes, comme la répartition par taille aux précédents hackathons.

La participation à distance dispense du coût des repas mais il faut ajouter celle des systèmes de communication utilisés, notamment Meetecho et Gather. (Avant de proposer un autre système, rappelez-vous qu'il y a des centaines de participant·es actif·ves au hackathon et qu'il faut une solution qui tienne la charge.)

À la fin du hackathon, les participant·es présentent leur travail, les résultats obtenus et les conclusions qu'on peut en tirer pour les normes en cours de développement (section 4). Au début, il y avait également une session de présentation des projets au début du hackathon mais elle a dû être abandonnée au fur et à mesure que le hackathon grossissait. La présentation initiale se fait désormais sur le Wiki (voir par exemple la prochaine et la page où on peut aller si on cherche une équipe ou bien des volontaires). C'est sur ce Wiki que les champions (les gens qui ont une idée et organisent une activité particulière au hackathon, cf section 7.4) essaient de recruter. Quant aux présentations finales, elles sont publiées sur Github. C'est aussi là qu'on trouvera le code produit lorsqu'il n'est pas sur un dépôt extérieur (section 5.6).

La liste des projets affichés dans la salle du hackathon de Yokohama en 2023 :

On a parlé des outils utilisés, lors de la section sur le financement. La section 5 dresse une liste plus complète des outils logiciels qui servent pour le hackathon. Il y a évidemment, comme pour tout travail IETF, le Datatracker (qui a une section sur le hackathon). Tout aussi évidemment, puisque l'IETF travaille largement avec des listes de diffusion, il y a une liste des participant·es au hackathon.

Pour profiter de tous ces outils, il faut un réseau à forte capacité, fiable, et évidemment sans aucun filtrage. Lors de la réunion de Beijing, les négociations avec les autorités avaient été serrées et l'accord final imposait un contrôle d'accès aux salles de l'IETF, pour éviter que des citoyens chinois n'en profitent. (Normalement, il n'y a aucun contrôle à l'entrée de l'IETF, personne ne vérifie les badges.) Le groupe qui s'occupe de monter et de démonter le réseau de l'IETF a donc en plus la charge du réseau du hackathon. Celui-ci peut en outre nécessiter des services spéciaux, afin de tester en présence de tels services (NAT64, prefix delegation, etc). Il y a même un accès VPN, pour celles et ceux qui travaillent à distance.

Parmi les différentes options qui peuvent être placées dans un en-tête d'un paquet IPv6, certaines sont à traiter par chaque routeur situé sur le trajet. On les appelle les options « par saut » (hop-by-hop). Elles sont très peu utilisées en pratique, entre autres parce que leur traitement, tel que spécifié dans le RFC 8200, est trop contraignant pour les routeurs. Ce nouveau RFC change donc les règles, dans le sens d'un plus grand pragmatisme.

À part l'en-tête « Hop-by-hop Options » (RFC 8200, section 4.3), tous les en-têtes IPv6 ne concernent que les machines terminales. « Hop-by-hop Options », lui, concerne les routeurs et, avant le RFC 8200, tous les routeurs sur le trajet avaient l'obligation de le lire et d'agir en fonction des options qu'il contenait (la liste complète des options possibles est dans un registre IANA). Bien trop coûteuse pour les routeurs, cette obligation a été supprimée par le RFC 8200. Ce nouveau RFC 9673 modifie le traitement des options de cet en-tête (et donc le RFC 8200) dans l'espoir qu'il voit enfin un vrai déploiement dans l'Internet (actuellement, cet en-tête par saut - hop-by-hop - est quasiment inutilisé). Si vous concevez des routeurs, et êtes pressé·e, sautez directement à la section 5 du RFC, qui décrit les nouvelles règles, mais ce serait dommage.

Petite révision sur l'architecture des routeurs (section 3 du RFC). Les routeurs de haut de gamme ont une voie rapide (fast path) pour le traitement des paquets, lorsque ceux-ci n'ont pas de demande particulière. Mise en œuvre en dehors du processeur principal du routeur, cette voie rapide est traitée par des circuits spécialisés, typiquement des ASIC. Si le paquet nécessite des opérations plus complexes, on passe par une voie plus lente, utilisant des méthodes et du matériel plus proches de ceux d'un ordinateur classique. (Les RFC 6398 et RFC 6192 sont des lectures recommandées ici.) D'autre part, on distingue souvent, dans le routeur, la transmission (forwarding plane) et le contrôle (control plane). La transmission est le travail de base du routeur (transmettre les paquets reçus sur une interface via une autre interface, et le plus vite possible), le contrôle regroupe notamment les opérations de manipulation de la table de routage, par exemple lors de mises à jour reçues via des protocoles comme OSPF ou BGP. Contrairement à la transmission, le contrôle n'est pas en « temps réel ».

Aujourd'hui, un paquet IPv6 utilisant des options par saut risque fort de ne même pas arriver à destination, sacrifié par des routeurs qui ne veulent pas le traiter. (Voir le RFC 7872, l'exposé « Internet Measurements: IPv6 Extension Header Edition » ou l'article « Is it possible to extend IPv6? ».)

Que disent donc les nouvelles procédures (section 5) ?

• Un routeur ne devrait pas jeter un paquet uniquement parce que celui-ci contient l'en-tête par saut (voir aussi RFC 9288). Même si le routeur ne traite pas les options de cet en-tête, il devrait transmettre le paquet.
• Il est très recommandé que les routeurs disposent d'une option de configuration permettant d'indiquer s'il faut ou non traiter les options par saut. Et d'une autre pour indiquer quelles options dans l'en-tête doivent être gérées, que cela ne soit pas du tout ou rien.
• IPv6 dispose de deux bits dans chaque option par saut pour indiquer le traitement souhaité du paquet si le routeur ne connait pas l'option. La nouvelle procédure permet d'être plus indulgent et, par exemple, de ne pas jeter un paquet même si l'émetteur le demandait, si le routeur ne veut pas traiter cette option (cf. le premier item de cette liste de règles).
• Les émetteurs qui mettent l'en-tête par saut dans les paquets doivent être bien conscients que tous les routeurs ne le traiteront pas (c'est le cas depuis longtemps, le RFC ne fait que décrire cet état de fait).
• Les machines terminales devraient examiner cet en-tête et le traiter, il ne concerne pas que les routeurs.

Pour faciliter la tâche des routeurs, et toujours dans l'espoir que les options par saut deviennent enfin une possibilité réaliste, la section 6 du RFC encadre la définition de nouveaux en-têtes (le RFC 8200 recommandait carrément de ne plus en définir, tant qu'on n'avait pas mieux défini leur utilisation). Les éventuelles futures options doivent être simples à traiter et conçues en pensant au travail qu'elles imposeront au routeur. Le protocole qui les utilise doit intégrer le fait que le routeur est autorisé à ignorer cette option, voire qu'il puisse jeter le paquet.

Ah, et un mot sur la sécurité (section 8). Plusieurs RFC ont déjà documenté les problèmes de sécurité que peuvent poser les options par saut, notamment le risque qu'elles facilitent une attaque par déni de service sur le routeur : RFC 6398, RFC 6192, RFC 7045 et RFC 9098.

Est-ce que le déploiement de ce RFC va améliorer les choses pour l'en-tête par saut, qui est jusqu'à présent un exemple d'échec ? Je suis assez pessimiste, étant donné la difficulté à changer des comportements bien établis.

Un peu d'histoire pour terminer (section 4 du RFC) : les premières normes IPv6 (RFC 1883, puis RFC 2460) imposaient à tous les routeurs d'examiner et de traiter les options par saut. Le RFC 7045 avait été le premier à constater que cette règle n'était pas respectée et ne pouvait pas l'être vu l'architecture des routeurs modernes. Le problème de performance dans le traitement des options était d'autant plus grave que les options n'avaient pas toutes le même format (cela a été résolu par le RFC 6564, qui imposait un format unique). Le résultat, comme vu plus haut, était que les routeurs ignoraient les options par saut ou, pire, jetaient le paquet qui les contenait. (Le RFC 9288 et l'article « Threats and Surprises behind IPv6 Extension Headers » expliquent pourquoi c'est une mauvaise idée. L'Internet Draft draft-ietf-v6ops-hbh discute également cette question.)

Les normes publiées par l'IETF ne sont pas que des documents techniques à seule destination des techniciens. L'Internet et, de manière plus générale, les protocoles TCP/IP sont aussi une grosse industrie qui brasse beaucoup d'argent. Il y a donc un risque que des acteurs de cette industrie essaient d'influencer les normes à leur profit, par exemple en formant des alliances qui, dans certains pays, seraient illégales au regard des lois antitrust. Ce court RFC administratif explique aux participant·es IETF ce que sont ces lois et comment éviter de les violer.

En effet, les organisations, notamment les entreprises à but lucratif, qui participent à l'IETF peuvent être concurrentes sur leurs marchés. Or, le développement de normes nécessite de la collaboration entre ces concurrents. Pour maintenir une concurrence et pour éviter les ententes, plusieurs pays ont des lois, dites « antitrust », lois que des participant·es à l'IETF ne connaissent pas forcément bien. La justification idéologique de ces lois est rappelée par le RFC, dans le cas étatsunien mais d'autres pays capitalistes ont des principes similaires : « Competition in a free market benefits consumers through lower prices, better quality and greater choice. Competition provides businesses the opportunity to compete on price and quality, in an open market and on a level playing field, unhampered by anticompetitive restraints. » Que ce soit vrai ou pas, peu importe, les lois antitrust doivent être respectées. Ce RFC n'édicte pas de règles pour l'IETF (« respectez la loi » est de toute façon déjà obligatoire), mais il explique des subtilités juridiques aux participant·es à l'IETF.

Il y a en effet deux risques pour l'IETF, qu'un·e représentant officiel de l'IETF soit accusé de comportement anti-concurrentiel, engageant la responsabilité de l'organisation, ou que des participant·es soient accusés de comportement anti-concurrentiel, ce qui n'engagerait pas la responsabilité de l'IETF mais pourrait affecter sa réputation.

Les participant·es à l'IETF sont censés suivre des règles dont certaines limitent déjà le risque de comportement anti-concurrentiel, entre autres :

• Suivre les procédures officielles (RFC 2026, RFC 2418 et plusieurs autres),
• Agir en tant qu'individu (RFC 7154) et non pas en tant que représentant de son employeur (ce qui est assez théorique, il faut bien le dire…), voir aussi cet article de l'administration de l'IETF,
• Respecter les règles concernant la propriété intellectuelle (RFC 5378 et RFC 8179),
• Et les règles sur le conflit d'intérêt (il y a celle de l'IESG, celle de l'IAB et enfin celle de l'organisation administrative de l'IETF ; mais les trois politiques sont très semblables).

Maintenant, s'y ajoutent les questions spécifiques au respect des lois sur la concurrence. La section 4, le cœur de ce RFC, attire l'attention sur :

• La nécessité d'éviter de parler de certains sujets comme les prix des produits, les marges bénéficiaires, les accords avec des tiers, les analyses marketing, bref tout ce qui concerne le business, auquel le RFC ajoute les salaires et avantages divers (allez au bistrot le plus proche si vous voulez en parler librement). Des discussions sur ces sujets ne violent pas forcément les lois antitrust mais, dans le doute, mieux vaut être prudent.
• L'importance de consulter un·e expert·e juridique en cas de doute. (L'IETF ne fournit pas de conseils juridiques.)
• Le fait que les problèmes peuvent être signalés à l'équipe juridique de l'IETF (legal@ietf.org) ou via le service spécifique pour les lanceurs d'alerte.

Ce RFC normalise une extension au protocole d'accès à l'information RDAP pour permettre des recherches inversées, des recherches par le contenu (« quels sont tous les noms de domaine de cette personne ? »).

Alors, tout d'abord, un avertissement. L'extension normalisée dans ce RFC est dangereuse pour la vie privée. Je détaille ce point plus loin mais ne réclamez pas tout de suite le déploiement de cette extension : lisez tout d'abord. C'est dès sa section 1 que le RFC met en garde contre un déploiement hâtif !

RDAP (normalisé dans les RFC 9082 et RFC 9083), comme son prédécesseur whois, permet d'obtenir des informations dites sociales (nom, adresse, numéro de téléphone, etc) sur les personnes (morales ou physiques) associées à une ressource Internet réservée, comme un nom de domaine ou un adresse IP. Une limite importante de ces deux protocoles est qu'il faut connaitre l'identifiant (nom de domaine, adresse IP) de la ressource. Or, certaines personnes seraient intéressés à faire l'inverse, découvrir les ressources à partir d'informations sociales. C'est le cas par exemple de juristes cherchant le portefeuille de noms de domaine de quelqu'un qu'ils soupçonnent de menacer leur propriété intellectuelle. Ou de chercheurs en sécurité informatique étudiant toutes les adresses IP utilisées par le C&C d'un botnet et voulant en découvrir d'autres. Ce RFC normalise justement un moyen de faire des recherches inverses. whois n'avait jamais eu une telle normalisation, à cause des risques pour la vie privée, risques qui sont peut-être moins importants avec RDAP.

(Notez quand même que le RFC 9082, section 3.2.1, prévoyait déjà certaines recherches inverses, d'un domaine à partir du nom ou de l'adresse d'un de ses serveurs de noms.)

Passons aux détails techniques (section 2). L'URL d'une requête inverse va inclure dans son chemin /reverse_search et, bien sûr, des critères de recherche. Par exemple, /domains/reverse_search/entity?fn=Jean%20Durand&role=registrant donnera tous les domaines dont le titulaire (registrant) se nomme Jean Durand (fn est défini dans la section 6.2.1 du RFC 6350). Le terme après /reverse_search indique le type des données auxquelles s'appliquent les critères de recherche (actuellement, c'est forcément entity, une personne morale ou physique).

La plupart des recherches inverses porteront sans doute sur quelques champs comme l'adresse de courrier électronique ou le handle (l'identifiant d'une entité). La section 8 décrit les possibilités typiques mais un serveur RDAP choisit de toute façon ce qu'il permet ou ne permet pas.

La sémantique exacte d'une recherche inverse est décrite en JSONPath (RFC 9535). Vous trouvez le JSONPath dans la réponse (section 5 du RFC), dans le membre reverse_search_properties_mapping. Par exemple :

"reverse_search_properties_mapping": [
    {
      "property": "fn",
      "propertyPath": "$.entities[*].vcardArray[1][?(@[0]=='fn')][3]"
    }
]
  

L'expression JSONPath $.entities[*].vcardArray[1][?(@[0]=='fn')][3] indique que le serveur va faire une recherche sur le membre fn du tableau vCard (RFC 7095). Oui, elle est compliquée, mais c'est parce que le format vCard est compliqué. Heureusement, on n'est pas obligé de connaitre JSONPath pour utiliser les recherches inverses, uniquement pour leur normalisation (section 3).

Pour savoir si le serveur RDAP que vous interrogez gère cette extension et quelles requêtes il permet, regardez sa réponse à la question help (RFC 9082, section 3.1.6, et RFC 9083, section 7) ; s'il accepte les requêtes inverses, vous y trouverez la valeur reverse_search dans le membre rdapConformance (section 9), par exemple :

"rdapConformance": [
    "rdap_level_0",
    "reverse_search"
]  
  

Pour les recherches acceptées, regardez le membre reverse_search_properties. Par exemple :

"reverse_search_properties": [
    {
      "searchableResourceType": "domains",
      "relatedResourceType": "entity",
      "property": "fn"
    }
]
  

Ici, le serveur indique qu'il accepte les requêtes inverses pour trouver des noms de domaine en fonction d'un nom d'entité (ce que nous avons fait dans l'exemple plus haut). Voir la section 4 pour les détails. Si vous tentez une requête inverse sur un serveur, et que le serveur n'accepte pas les requêtes inverses, ou tout simplement n'accepte pas ce type particulier de recherche inverse que vous avez demandé, il répondra avec le code de retour HTTP 501 (section 7). Vous aurez peut-être aussi un 400 si votre requête déplait au serveur pour une raison ou l'autre.

L'extension est désormais placée dans le registre des extensions RDAP. En outre, deux nouveaux registres sont créés, RDAP Reverse Search, pour les recherches possibles et RDAP Reverse Search Mapping pour les règles JSONPath. Pour y ajouter des valeurs, la politique (RFC 8126) est « spécification nécessaire ».

Revenons maintenant aux questions de vie privée (RFC 6973), que je vous avais promises. La section 12 du RFC détaille le problème. La puissance des recherches inverses les rend dangereuses. Une entreprise concurrente pourrait regarder vos noms de domaine et ainsi se tenir au courant, par exemple, d'un nouveau projet ou d'un nouveau produit. Un malveillant pourrait regarder les noms de domaine d'une personne et identifier ainsi des engagements associatifs que la personne ne souhaitait pas forcément rendre très visibles. Les données stockées par les registres sont souvent des données personnelles et donc protégées par des lois comme le RGPD. Le gestionnaire d'un serveur RDAP doit donc, avant d'activer la recherche inverse, bien étudier la sécurité du serveur (section 13) mais aussi (et ce point n'est hélas pas dans le RFC) se demander si cette activation est vraiment une bonne idée.

En théorie, RDAP pose moins de problème de sécurité que whois pour ce genre de recherches, car il repose sur HTTPS (le chiffrement empêche un tiers de voir questions et réponses) et, surtout, il permet l'authentification ce qui rend possible, par exemple, de réserver les recherches inverses à certains privilégiés, avec un grand choix de contrôle d'accès (cf. annexe A). Évidemment, cela laisse ouvertes d'autres questions comme « qui seront ces privilégiés ? » et « comment s'assurer qu'ils n'abusent pas ? » (là, les journaux sont indispensables pour la traçabilité, cf. l'affaire Haurus).

Notons qu'outre les problèmes de vie privée, la recherche inverse pose également des problèmes de performance (section 10). Attention avant de la déployer, des requêtes apparemment innocentes pourraient faire ramer sérieusement le serveur RDAP. Si vous programmez un serveur RDAP ayant des recherches inverses, lisez bien les recommandations d'optimisation de la section 10, par exemple en ajoutant des index dans votre SGBD. Et le serveur ne doit pas hésiter, en cas de surcharge, à répondre seulement de manière partielle (RFC 8982 ou RFC 8977).

Je n'ai pas trouvé de code public mettant en œuvre ces recherches inverses. De même, je ne connais pas encore de serveur RDAP déployé qui offre cette possibilité.

Aujourd'hui, le terme de « sabotage » renvoie uniquement à des activités sournoises et clandestines, non revendiquées officiellement. Mais, à une époque, le terme était ouvertement discuté dans certaines organisations ouvrières, et considéré par certains comme un moyen de lutte parmi d'autres. Ce livre revient sur l'histoire du concept de sabotage, notamment à propos des débats qu'il avait suscité dans le mouvement ouvrier.

C'est difficile de parler du sabotage aujourd'hui car le concept a été brouillé par les médias qui l'ont présenté systématiquement comme un acte destructeur, voire meurtrier. Or, lorsque le terme a été popularisé en France à la fin du XIXe siècle, c'était dans un sens triplement différent : il n'était pas forcément destructeur (le simple ralentissement de la cadence était inclus dans le sabotage), il était revendiqué publiquement et, surtout, il faisait l'objet de nombreuses discussions ayant pour but d'en fixer les limites (notamment le tabou de la violence contre les personnes). Car, à la Belle Époque, un syndicat comme la CGT pouvait ouvertement inscrire le sabotage dans ses résolutions votées au congrès.

Le livre se focalise sur deux moments de cette politisation du sabotage. L'acte lui-même est certainement bien plus ancien mais la nouveauté, due notamment à Pouget, était d'en faire un moyen de lutte collective, assumé comme tel.

Après la période française, la revendication publique du sabotage a connu une deuxième période, aux États-Unis, où l'IWW en faisait un de ses moyens d'action. (Le livre rappelle, et c'est très important, le contexte de la lutte de classes aux USA, marqué par une extrême violence patronale, avec utilisation fréquente de milices privées qui, elles, n'avaient aucun scrupule à utiliser la violence contre les personnes, et en toute impunité.) Le livre détaille ces deux périodes, et met l'accent sur les innombrables discussions politiques au sein du mouvement ouvrier autour du sabotage, de sa légitimité, de ses liens avec les autres formes de lutte et avec les travailleurs, des limites qu'on s'impose, et des risques, qu'ils soient d'accident, de débordement par des irresponsables, ou de difficulté à empêcher la diabolisation par les médias et les politiciens. À la fin, aussi bien la CGT que l'IWW ont renoncé à mentionner le sabotage, en partie à cause des difficultés qu'il y avait à l'expliquer aux travailleurs. (Et aussi à le contrôler : l'auteur cite Jaurès qui disait que le sabotage était la forme de lutte qu'il fallait le plus contrôler, alors qu'elle était aussi la plus difficile à contrôler.) Cela n'a pas mis fin au sabotage : l'auteur note qu'en France, il y a même eu davantage de sabotages après que la CGT l'ait retiré de son programme.

J'ai noté que l'auteur parlait très peu de la Résistance, un autre moment où le sabotage était assumé et glorifié. Mais c'est sans doute que, là, il n'y avait pas de débat : aucun résistant ne discutait la légitimité du sabotage sans limite. L'OSS les aidait même, avec son fameux « manuel du sabotage » (qui, il faut le rappeler, incluait aussi des méthodes non destructrices comme de ralentir le travail).

Pour d'autres périodes, l'auteur expose les différentes façons de pratiquer le sabotage, incluant par exemple la grève du zèle. Il cite l'exemple du « sabotage de la bouche ouverte » chez les serveurs de restaurant au début du XXe siècle : on sert le client mais on lui dit tout ce qu'il y a vraiment dans le plat servi. De nombreuses idées astucieuses de ce genre ont surgi dans le débat.

Le sabotage, qui était bien plus ancien que le livre de Pouget, reste toujours d'actualité, comme on l'a vu dans l'affaire de Tarnac (jamais élucidée, notamment en raison du comportement des enquêteurs qui, certains de tenir les coupables, ont bâclé l'enquête) ou dans les récentes attaques contre les liaisons Internet, là aussi non revendiquées. (Il y en avait eu aussi en avril 2022, cf. article de Numérama et article du Nouvel Obs.) On est à l'opposé des théories des « syndicalistes révolutionnaires » du XIXe siècle puisqu'on atteint le degré zéro de la politique : aucune idée sur les auteurs de ces coupures et leur but.

Dans le contexte du Web, la viralité est un terme emprunté, évidemment, à l'épidémiologie, pour désigner une propagation rapide, de proche en proche, d'une information. En tant que phénomène social, elle peut être étudiée et c'est ce que fait ce livre collectif sur la viralité.

Bien des commerciaux et des politiciens se demandent tous les jours comment atteindre cet objectif idéal, la viralité, ce moment où les messages que vous envoyez sont largement repris et diffusés sans que vous ayiez d'effort à faire. Cela intéresse aussi évidemment les chercheur·ses en sciences humaines, d'où ce livre. (Et le projet HIVI, et le colloque qui aura lieu du 18 au 20 novembre 2024 à l'université du Luxembourg.) La version papier du livre coûte cher mais vous pouvez le télécharger légalement (le lien pour avoir tout le livre, et pas chapitre par chapitre, peut être difficile à voir : regardez en haut à droite).

Il y a de nombreux points à discuter dans la viralité et vous trouverez certainement dans ces études des choses intéressantes. Par exemple, le rôle des outils. Dans quelle mesure les programmes avec lesquels vous interagissez encouragent ou découragent la viralité ? Et, si le débat politique tourne en général exclusivement autour du rôle des GAFA et des mythifiés « algorithmes », il ne faut pas oublier que les médias traditionnels jouent aussi un rôle dans la viralité, en validant que telle ou telle information est « virale ».

N'oublions pas non plus que la viralité des informations n'est pas arrivée avec l'Internet. Le Kilroy was here des soldats étatsuniens de la deuxième guerre mondiale est un bon exemple de viralité avant les réseaux informatiques.

Mon chapitre préféré, dans ce livre, a été celui de Gastón Arce-Pradenas sur le succès viral et, souvent, la chute, de personnalités du mouvement chilien de 2019. Comme souvent dans un mouvement peu organisé (on pense évidemment aux gilets jaunes français, qui ont également vu ce genre de phénomène), des personnalités émergent sans mandat particulier, choisies par les médias, et/ou bénéficiant d'un succès viral, aidé par des techniques de communication spectaculaires, avant de trébucher rapidement. Ne ratez pas l'histoire du dinosaure bleu, par exemple, une des plus fascinantes. Vous aurez d'ailleurs d'autres perspectives internationales, par exemple du Brésil avec l'étude de Nazaré Confusa. La viralité ne concerne pas que les sujets étatsuniens.

Un peu de critique, toutefois : le livre est inégal, et certaines contributions n'ont pas de rapport direct avec la notion de viralité.

Et si le sujet vous fascine :

• Une fresque chronologique d'informations virales fameuses et une version spécialisée dans les chats (what else?).
• À propos de chats, une des auteures du livre a donné un bon interview sur la viralité féline.
• La viralité concerne souvent un mème, un point de départ qu'on peut décliner donc, si vous voulez tout savoir sur un mème particulier, il faut aller voir knowyourmeme.com.
• L'excellente série télévisée Le dessous des images parle souvent d'images virales.

Ce RFC marque l'arrivée d'un nouvel algorithme de signature dans les enregistrements DNSSEC, algorithme portant le numéro 23. Bienvenue au GOST R 34.10-2012 (alias ECC-GOST12), algorithme russe, spécifié en anglais dans le RFC 7091, une légère mise à jour de GOST R 34.10-2001.

La liste des algorithmes DNSSEC est un registre à l'IANA, https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml#dns-sec-alg-numbers-1. Elle comprend désormais GOST R 34.10-2012 (qui succède au R 34.10-2001 du RFC 5933). Notez que GOST désigne en fait une organisation de normalisation, le terme correct serait donc de ne jamais dire « GOST » tout court, mais plutôt « GOST R 34.10-2012 » pour l'algorithme de signature et « GOST R 34.11-2012 » pour celui de condensation, décrit dans le RFC 6986 (voir la section 1 de notre RFC 9558).

La section 2 décrit le format des enregistrements DNSKEY avec GOST, dans lequel on publie les clés GOST R 34.10-2012. Le champ Algorithme vaut 23, le format de la clé sur le réseau suit le RFC 7091. GOST est un algorithme à courbes elliptiques, courbes décrites par Q = (x,y). Les 32 premiers octets de la clé sont x et les 32 suivants y (en petit-boutien, attention, contrairement à la majorité des protocoles Internet).

Parmi les bibliothèques cryptographiques existantes, au moins OpenSSL met en œuvre GOST R 34.10-2012 (testé avec la version 3.3.2). Voir RFC 9215 pour de l'aide à ce sujet. Sinon, on trouve parfois seulement l'ancienne version dans certains logiciels et certaines bibliothèques.

La section 2.2 donne un exemple de clé GOST publiée dans le DNS, je n'ai pas trouvé d'exemple réel dans la nature, même en .ru.

La section 3 décrit le format des enregistrements RRSIG, les signatures (avec un exemple). On suit les RFC 5958 et RFC 7091. Attention, une particularité de GOST fait que deux signatures des mêmes données peuvent donner des résultats différents, car un élément aléatoire est présent dans la signature.

La section 4 décrit le format des enregistrements DS pour GOST. La clé publique de la zone fille est condensée par GOST R 34.11-2012, algorithme de numéro 5.

Les sections 5 et 6 couvrent des questions pratiques liées au développement et au déploiement de systèmes GOST, par exemple un rappel sur la taille de la clé (512 bits) et sur celle du condensat cryptographique (256 bits).

GOST peut se valider avec Unbound si la bibliothèque de cryptographie utilisée gère GOST. Et, comme indiqué plus haut, ce ne sera sans doute que l'ancienne version, celle du RFC 5933. Pour les programmeurs Java, DNSjava a le dernier GOST depuis la version 3.6.2. Pour le statut (recommandé ou non) de l'algorithme GOST pour DNSSEC, voir le RFC 8624. En Python, dnspython en version 2.7.0 n'a que l'ancien algorithme.

Matroska est un format de conteneur pour du contenu multimédia (son, image, sous-titres, etc). Ce n'est pas un format de données (format utilisé par un codec), mais un moyen de regrouper de manière structurée des données différentes.

Je vous préviens tout de suite, le RFC fait 167 pages, et, en prime, le multimédia n'est pas ma spécialité. Donc, je vais faire court. Matroska est fondé sur un langage qui utilise le modèle de données XML, EBML (normalisé dans le RFC 8794). Notre nouveau RFC 9559 est donc surtout une très longue liste des éléments XML qu'on peut y trouver (Matroska est riche !), encodés en binaire. Matroska n'est pas nouveau (il en est à la version 4), mais c'est sa première normalisation. Notez que vous trouverez de l'information sur la page Web du projet.

Le caractère hiérarchique d'un fichier Matroska (des éléments dans d'autres éléments) est bien rendu par cet outil (qui fait partie de MKVToolNix, cité plus loin) :

    
% mkvinfo ./format/matroska/testdata/sweep-with-DC.mkvmerge13.mka
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ Maximum EBML ID length: 4
|+ Maximum EBML size length: 8
|+ Document type: matroska
|+ Document type version: 4
|+ Document type read version: 2
+ Segment: size 18507
|+ Seek head (subentries will be skipped)
|+ EBML void: size 4031
|+ Segment information
| + Timestamp scale: 22674
| + Multiplexing application: libebml v1.4.2 + libmatroska v1.6.2
| + Writing application: mkvmerge v52.0.0 ('Secret For The Mad') 64-bit
| + Duration: 00:00:02.607714066
| + Date: 2022-08-28 18:32:21 UTC
| + Segment UID: 0x3b 0x9f 0x28 0xc7 0xc4 0x90 0x8a 0xe0 0xcd 0x66 0x8f 0x11 0x8f 0x7c 0x2f 0x54
|+ Tracks
| + Track
|  + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
|  + Track UID: 3794791294650729286
|  + Track type: audio
|  + Codec ID: A_FLAC
|  + Codec's private data: size 133
|  + Default duration: 00:00:00.040634920 (24.609 frames/fields per second for a video track)
|  + Language: und
|  + Language (IETF BCP 47): und
|  + Audio track
|   + Sampling frequency: 44100
|   + Bit depth: 16
|+ EBML void: size 1063
|+ Cluster

  

On voit un document de la version 4 (celle du RFC), commençant (forcément, cf. section 4.5 du RFC) par un en-tête EBML, et comportant une seule piste (l'élément Tracks est décrit en section 5.1.4), un son au format FLAC (RFC 9639). L'extension .mka est souvent utilisée pour des conteneurs n'ayant que de l'audio (et .mkv s'il y a de la vidéo). La piste audio est dans une langue indéterminée, und. Plusieurs éléments existent pour noter la langue car Matroska n'utilisait autrefois que la norme ISO 639 mais la version 4 recommande les bien plus riches étiquettes de langue IETF (RFC 5646, alias « IETF BCP 47 »).

Un autre document a deux pistes, le son et l'image :

% mkvinfo ~/Videos/2022-01-22\ 13-17-28.mkv 
…
|+ Tracks
| + Track
|  + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
|  + Track UID: 1
|  + "Lacing" flag: 0
|  + Language: und
|  + Codec ID: V_MPEG4/ISO/AVC
|  + Track type: video
|  + Default duration: 00:00:00.033333333 (30.000 frames/fields per second for a video track)
|  + Video track
|   + Pixel width: 852
|   + Pixel height: 480
|   + Display unit: 4
|  + Codec's private data: size 41 (H.264 profile: High @L3.1)
| + Track
|  + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
|  + Track UID: 2
|  + "Lacing" flag: 0
|  + Name: simple_aac_recording
|  + Language: und
|  + Codec ID: A_AAC
|  + Track type: audio
|  + Audio track
|   + Channels: 2
|   + Sampling frequency: 44100
|   + Bit depth: 16
|  + Codec's private data: size 5

  

L'arborescence des fichiers Matroska peut être très profonde et ça se reflète dans la numérotation des sections du RFC (il y a une section 5.1.4.1.28.18 !).

Les types MIME à utiliser sont audio/matroska et video/matroska (section 27.3 du RFC).

Il existe plusieurs mises en œuvre de Matroska en logiciel libre comme MKVToolNix, qui sait faire beaucoup de choses (comme afficher les éléments Matroska comme vu plus haut) et qui existe en ligne de commande ou GUI. Et VLC sait évidemment jouer les fichiers Matroska. OBS, quant à lui, permet d'en produire. Par exemple, cette vidéo sans intérêt a été faite avec OBS.

Cette nouvelle option du DNS permet au client d'obtenir du serveur le numéro de version de la zone servie. (Et, non, le numéro de série dans l'enregistrement SOA ne suffit pas, lisez pour en savoir plus.)

Cela permettra de détecter les problèmes de mise à jour des serveurs faisant autorité si, par exemple, un des secondaires ne se met plus à jour. C'est surtout important pour l'anycast, qui complique le déboguage. En combinaison avec le NSID du RFC 5001, vous trouverez facilement le serveur qui a un problème. Cette nouvelle option ressemble d'ailleurs à NSID et s'utilise de la même façon.

Vous le savez, le DNS ne garantit pas que tous les serveurs faisant autorité d'une zone servent la même version de la zone au même moment. Si je regarde la zone .com à cet instant (14 juillet 2024, 09:48 UTC) avec check-soa, je vois :

% check-soa com
a.gtld-servers.net.
	2001:503:a83e::2:30: OK: 1720950475
	192.5.6.30: OK: 1720950475
b.gtld-servers.net.
	192.33.14.30: OK: 1720950475
	2001:503:231d::2:30: OK: 1720950475
c.gtld-servers.net.
	2001:503:83eb::30: OK: 1720950475
	192.26.92.30: OK: 1720950475
d.gtld-servers.net.
	2001:500:856e::30: OK: 1720950475
	192.31.80.30: OK: 1720950475
e.gtld-servers.net.
	2001:502:1ca1::30: OK: 1720950475
	192.12.94.30: OK: 1720950475
f.gtld-servers.net.
	2001:503:d414::30: OK: 1720950475
	192.35.51.30: OK: 1720950475
g.gtld-servers.net.
	192.42.93.30: OK: 1720950475
	2001:503:eea3::30: OK: 1720950475
h.gtld-servers.net.
	192.54.112.30: OK: 1720950475
	2001:502:8cc::30: OK: 1720950475
i.gtld-servers.net.
	2001:503:39c1::30: OK: 1720950460
	192.43.172.30: OK: 1720950475
j.gtld-servers.net.
	2001:502:7094::30: OK: 1720950475
	192.48.79.30: OK: 1720950475
k.gtld-servers.net.
	192.52.178.30: OK: 1720950460
	2001:503:d2d::30: OK: 1720950475
l.gtld-servers.net.
	192.41.162.30: OK: 1720950475
	2001:500:d937::30: OK: 1720950475
m.gtld-servers.net.
	2001:501:b1f9::30: OK: 1720950475
	192.55.83.30: OK: 1720950475

On observe que, bien que le numéro de série dans l'enregistrement SOA soit 1720950475, certains serveurs sont restés à 1720950460. Le DNS est « modérement cohérent » (RFC 3254, sur ce concept).

Dans l'exemple ci-dessus, check-soa a simplement fait une requête pour le type de données SOA (section 4.3.5 du RFC 1034). Une limite de cette méthode est que, si on observe des données d'autres types qui ne semblent pas à jour et que, pour vérifier, on fait une requête de type SOA, on n'a pas de garantie de tomber sur le même serveur, notamment en cas d'utilisation d'anycast (RFC 4786) ou bien s'il y a un répartiteur de charge avec plusieurs serveurs derrière. (D'ailleurs, dans l'exemple ci-dessus, vous avez remarqué que vous n'avez pas la même réponse en IPv4 et IPv6, probablement parce que vous arriviez sur deux instances différentes du nuage anycast.) Il faut donc un mécanisme à l'intérieur même de la requête qu'on utilise, comme pour le NSID. C'est le cas du ZONEVERSION de ce RFC, qui permet d'exprimer la version sous forme d'un numéro de série (comme avec le SOA) ou par d'autres moyens dans le futur, puisque toutes les zones n'utilisent pas le mécanisme de synchronisation habituel du DNS. On peut par exemple avoir des zones entièrement dynamiques et tirées d'une base de données, ou bien d'un calcul.

Notez aussi que certaines zones, comme .com, changent très vite, et que donc, même si on tombe sur le même serveur, le numéro de série aura pu changer entre une requête ordinaire et celle pour le SOA. C'est une raison supplémentaire pour avoir le mécanisme ZONEVERSION.

Bref, le nouveau mécanisme (section 2 du RFC), utilise EDNS (section 6.1.2 du RFC 6891). La nouvelle option EDNS porte le numéro 19. Encodée en TLV comme toutes les options EDNS, elle comprend une longueur et une chaine d'octets qui est la version de la zone. La longueur vaut zéro dans une requête (le client indique juste qu'il souhaite connaitre la version de la zone) et, dans la réponse, une valeur non nulle. La version est elle-même composée de trois champs :

• Le nombre de composants dans le nom de domaine pour la zone concernée. Si la requête DNS portait sur le nom de domaine foo.bar.example.org et que le serveur renvoie la version de la zone example.org, ce champ vaudra deux.
• Le type de la version. Différents serveurs faisant autorité utiliseront différentes méthodes pour se synchroniser et auront donc des types différents. Pour l'instant, un seul est normalisé, le 0 (alias SOA-SERIAL), qui est le numéro de série, celui qu'on trouverait dans le SOA, cf. section 3.3.13 du RFC 1035. La longueur sera donc de 6, les 4 octets de ce numéro, le type et le nombre de composants, un octet chacun. Un nouveau registre IANA accueillera peut-être d'autres types dans le futur, suivant la procédure « spécification nécessaire » du RFC 8126. (Cette procédure nécessite un examen par un expert, et la section 7.2.1 guide l'expert pour ce travail.)
• La valeur à proprement parler.

Si vous voulez voir dans un pcap, regardez zoneversion.pcap.

L'option ZONEVERSION n'est renvoyée au client qui si celui-ci l'avait demandé, ce qu'il fait en mettant une option ZONEVERSION vide dans sa requête (section 3 du RFC). Si le serveur fait autorité pour la zone concernée (ou une zone ancêtre), et qu'il gère cette nouvelle option, il répond avec une valeur. Même si le nom demandé n'existe pas (réponse NXDOMAIN), l'option est renvoyée dans la réponse.

Comme les autres options EDNS, elle n'est pas signée par DNSSEC (section 8). Il n'y a donc pas de moyen de vérifier son authenticité et elle ne doit donc être utilisée qu'à titre informatif, par exemple pour le déboguage. (En outre, elle peut être modifiée en route, sauf si on utilise un mécanisme comme DoT - RFC 7858.)

Question mises en œuvre de cette option, c'est surtout du code expérimental pour l'instant, voir cette liste (pas très à jour ?). Personnellement, j'ai ajouté ZONEVERSION à Drink, et écrit un article sur l'implémentation d'options EDNS (mais notez que l'option a changé de nom et de format depuis). Notez que, contrairement à presque toutes les options EDNS, ZONEVERSION est par zone, pas par serveur, ce qui est une contrainte pour le ou la programmeureuse, qui ne peut pas choisir la valeur avant de connaitre le nom demandé. Du côté des autres logiciels, NSD a vu un patch (mais apparemment abandonné). Voici ce que voit dig actuellement (en attendant une intégration officielle de l'option) :

% dig +ednsopt=19 @ns1-dyn.bortzmeyer.fr dyn.bortzmeyer.fr SOA 
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64655
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1440
; OPT=19: 03 00 78 a5 08 cc ("..x...")
…

;; ANSWER SECTION:
dyn.bortzmeyer.fr.	0 IN SOA ns1-dyn.bortzmeyer.fr. stephane.bortzmeyer.org. (
				2024081612 ; serial
…

Vous noterez que "03" indique trois composants (dyn.bortzmeyer.fr), "00" le SOA-SERIAL, et "78 a5 08 cc" égal 2024081612. Vous pouvez aussi tester ZONEVERSION avec le serveur de test 200.1.122.30 (un NSD modifié), avec le domaine example.com.